Activity-Oriented Access Control (AOAC) Model

 
Abstract
In hospital information systems, protecting the confidentiality of health information, whilst at the same time allowing authorized physicians to access it conveniently, is a crucial requirement. The need to deliver health information at the point-of-care is a primary factor to increase healthcare quality and cost efficiency. However, current systems require considerable coordination effort of hospital professionals to locate relevant documents to support a specific activity. This study was to design and develop a flexible and dynamic access control model, Activity-Oriented Access Control (AOAC), which is based on user activity to authorize access permissions. A user is allowed to perform an activity if he/she holds a number of satisfactory attributes (i.e. roles, assignments, etc.) under a specified condition (e.g. time, location). Results of AOAC implementation in a realistic healthcare scenario have shown to meet two important requirements: protecting confidentiality of health information by denying an unauthorized access, and allowing physicians to conveniently browse medical data at the point-of-care.
 
Brief Description
Current hospital information systems require considerable coordinated effort of physicians to find and browse relevant data to support a specific healthcare activity. They have to constantly log in and out of devices, start and stop sets of applications, look for the types of information needed for their clinical care and browse information repeatedly. For example, when a physician discusses with other physicians about a patient's progress, he/she has to manually browse the patient's electronic medical record to see the progress; at a patient's bedside, after checking the patient's health status, the physician has to manually open the diagnosis and treatment record of this patient to update it; when the physician diagnoses a patient with a broken leg, he/she has to manually browse the electronic X-ray images provided by a radiologist. These examples show significant efforts by the physician to search and browse different medical data that he/she needs for his/her activity.

In order to avoid wastage of time and resources and to increase efficiency of professional hospital work, a new access control model is required.
  • First, the access control mechanism should be able to dynamically grant permission to a physician to access all data related to a healthcare activity.
  • Second, the mechanism should be able to flexibly permit or revoke permission when the physician is or is not allowed to perform an activity.
  • Third, the access control mechanism should be able to automatically provide the right medical data at the right time so as to reduce the physician's effort to search and browse the medical data.


Most of current solutions are based on user identification (ID) or user's role [1-8]. They are application - dependent and do not address the intricate security requirements of hospital applications. Ubiquitous hospital systems require flexible, extensible, context-aware and dynamic authorization enforcement. The policy specification of these models tightly couples ID/role of users with their permissions. This coupling does not support user tasks. In [9,10], accessing time, user location and other contexts were applied as a foundation to authorize access permission. However, this context is general and it does not indicate user activities. Considerable effort must be spent to adapt these approaches in reality to provide information and services to users at the point-of-care. In study, we propose a new access control model based on user activity, Activity- Oriented Access Control (AOAC), to address aforementioned security requirements in hospital applications

AOAC employs the role concept from RBAC, but extends further than RBAC to provide a flexible and dynamic access control mechanism. In RBAC, authorization is based on user's role such as doctor or nurse. It does not consider the specific activities a physician may have to perform. Consequently, the physician has to spend considerable effort to browse information he/she needs for each activity he/she is doing. AOAC can reduce effort by recognizing what he/she is doing and dynamically providing such information to him/her. To do this, AOAC controls access permissions to hospital information and services based on the user activity. A user is allowed to perform an activity if he/she holds a number of satisfactory attributes (i.e., roles, assignments, etc.) under a certain environment constraint. For example, Dr. John is assigned to diagnose a patient Carol. To carry out this activity, John needs access permissions to Carol's medical record, X-ray image, and blood test result. As the system knows that the doctor performs ''Pneumonia treatment for patient Carol", all related medical information would be displayed to him. Such information is of course authorized to the doctor. If an activity (task) is revoked, all corresponding privileges become invalid without human intervention. In the above example, if the doctor's ''Pneumonia treatment for patient Carol", activity is revoked, all access privileges related to this activity become invalid without human intervention. RBAC requires more effort to make it work, because a role may involve various activities. Although some access privileges are no longer needed for an activity, they are still available to that role. For example, with a role 'doctor', a person may be assigned several treatments. Consequently, he/she is conferred a right to access information related to his/her patients. Once a treatment for a patient is accomplished, access permissions to that patient's information are still available. Therefore, RBAC requires extra effort to disable those access privileges.

The nature of organizational authorizations is determining who is allowed to do what. For example, Dr. John is permitted to carry out treatment of pneumonia for patient Carol. Therefore, by associating a user with activities, we can easily match the AOAC into real environments. In order to accomplish an action, a user needs access permissions to a number of resources. By connecting each activity with access permissions, the proposed model highly supports user activity. Therefore, we abstract the access control model in three levels: user level, activity level, and privilege level, as illustrated in Fig. 1


Figure 1. AOAC abstraction levels


Fig. 2 shows AOAC model. It is comprised of five administrative elements: (1) users (i.e. user's attributes), (2) activities and (3) permissions (i.e. privileges), where permissions are composed of (4) objects and (5) operations. User is a human interacting with a computing system. Activity is a human activity. It differs from the term 'task' in a workflow system in the sense that is does not model nor control real-world human activities. An activity can be created and modified according to the desire of the user. Object is medical data as well as system resource. An operation is an executable image of a program, for example 'read', 'write', 'execute'. Permission is an authorization to perform certain operations within the system. Constraint, similar to the concept of constraint from RBAC model [4], is defined as a predicate that is applied to a relation between two elements returning a value of 'acceptable' or 'not-acceptable'. In the AOAC model, Activity Activation Rule (AAR) is to allow a user to perform a certain activity if he/she holds a number of attributes including roles, user ID, and other credentials (e.g. an assignment). Permission Activation Rule (PAR) is to provide access permissions to an activity. Technically, AOAC differs from RBAC in that a role in AOAC is considered as an attribute of a user and it alone cannot decide what permission is allowed. It is not a bridge to connect between a user and permission. Permission is only directly connected to an activity which a user is allowed to perform. Therefore, if a user holds a number of roles, it will not cause any conflict of authorization like in RBAC model.

Figure 2. AOAC model.
We have implemented the AOAC model for a realistic sample scenario to show how the system works and fulfills the aforementioned requirements. The AOAC system design is shown in Fig. 3. Activity Recognition Manager (ARM) detects user's activities. User's attributes, activities and activity activation rules are stored on a Lightweight Directory Access Protocol (LDAP) server. Permission activation rules are defined by eXtensible Access Control Markup Language (XACML) [15]. To be compliant with XACML standard, AOAC integrates a Policy Enforcement Point (PEP), and a Policy Decision Point (PDP). PEP makes decision of requests and enforcing authorization decisions. PEP incorporates a Trigger module to ease access. Once AOAC identifies authorized activity and access privileges, the trigger can deliver that information to users at the point-of-care. PDP evaluates applicable policy and renders and authorization decision. PDP is composed of three sub-components: User-Attribute Manager (UAM), which retrieves user's attributes according to user identifier (uid) from user's attributes LDAP server; Attribute-Activity Manager (AAM), which matches user's attributes to a set of allowed activities; and Activity-Permission Manager (APM), which retrieves all access privileges for given activities from XACML policies. The Admin Tool (AT) is used to define activities and policies. Possible activities in the hospital are predicted and defined in advance. In fact, the bootstrapping phase is not much more onerous than other approaches such as RBAC

Figure 3. AOAC system design..
 
Discussion
In general, there are different ways to protect the confidentiality of data. One way is to protect at the communication level by a strong encryption algorithm such as Advanced Encryption Standard (AES). Another way is to protect at the application level, in which access of unauthorized user are prohibited by an access control mechanism. In this paper, the confidentiality of medical record is protected at the application layer by the proposed access control mechanism. We extended the sample scenario with different activities, such as medical treatment, diagnosis, admission/discharge, taking notes, medical prescription. When a physician was performing an activity, he/she entered it into the pop-up dialog-box, and then corresponding data was shown. In several cases, we also asked the physicians to intentionally enter an activity that they are not permitted to perform. Because the activity is not allowed, the corresponding access permissions are prohibited. Consequently, none of information was provided to them. That indicates AOAC meets the first requirement mentioned in Section 4. The hospital information maintains confidentiality without hindering patient's care by denying legitimate access request to hospital employees. If the activity was permitted, the system correctly and instantly provided related information and services to physicians and nurses. This shows AOAC meets the second requirement mentioned in Section 4. It delivers appropriate information to physicians at the point-of-care. The experiment was repeated 70 times with different scenarios. It ran on a PC server (Pentium IV 3.2 GHz and 1 GB of RAM) with the average execution time of approximately 0.078 s. That included receiving an activity description, processing authorization, and displaying appropriate data to users. This means that AOAC is able to work in real-time. In the first phase of implementation, we have not optimized the code. We believe that if the optimization is taken into account, the performance will be significantly improved. Even when the user performs many activities simultaneously, the execution time will not be significantly increased.

We have considered the situation where many simultaneous activities are executed. However, it is not an issue for the access control mechanism because we have observed that the execution time was not increasing when we increased the number of simultaneous activities. On the other hand, if our experiment was deployed on a faster PC server, the execution time would be decreased significantly. However, when many simultaneous activities are executed, the execution time of Activity Recognition (in case we apply Activity Recognition engine instead of the dialog-box) will be an issue. To address this issue, we are considering a solution of using Cloud Computing, as mentioned in our on-going work (SC3) [17]. By taking advantage of Cloud Computing, we can increase the performance and decrease the financial cost of the system. Our next version will present the performance of a complete system including the Activity Recognition engine.

In our experiment, we have not considered the case that a user performs more than one activity at the same time because it affects the activity recognition mechanism. In particular, it adds high complexity to the activity recognition mechanism because the activity recognition depends on various sensing devices to gather activity context. When a user performs more than one activity, the sensing devices and recognition engine should be able to differentiate these activities. Our future work will address this issue.
 
Conclusion
The Activity-Oriented Access Control (AOAC) model was proposed to increase efficiency of the healthcare professionals. Through the implementation, we showed that AOAC is more flexible than RBAC by meeting two important requirements: protecting confidentiality of health information by denying an unauthorized access, and allowing physicians to conveniently brow medical data at the point-of-care. Furthermore, the average execution time was 0.078 s which allows AOAC to work in real-time.

We implemented a simple dialog-box for users to explicitly state their activity. However, this is not the 'best' choice. Instead, we plan to integrate our activity recognition engine to completely fulfill AOAC's goal. Currently, we are working on two activity recognition approaches: embodied-sensor based activity recognition [18] and embedded-sensor based activity recognition [19]. With an ontology engine and learning mechanism, the system will be able to work in real-time. In the former approach, a single sensor is attached to each person. It supports gyroscope and three-axis accelerometer measurement. An activity is predicted or inferred based on the gyroscope and accelerometer information. Activity history is also used to increase the accuracy of current activity detection. In the latter approach, a group of sensors is attached to objects and the surrounding environment, for example on a wall, a monitor, an electronic notepad, a medicine tray, a patient bed. Normally, when a person performs an activity, he/she must use a number of objects/tools. Whenever an object/tool is used, the attached sensor will report a signal to the central server. Using a sequence of these signals, we can predict or infer what the user is doing. Therefore, we will eventually be able to integrate our activity recognition engine.
 
Publications
  1. Le XH, Lee S, Lee Y-K, Lee H, Khalid M, and Sankar R, 'Activity-oriented access control to ubiquitous hospital information and services', Information Sciences (Elsevier),2010, 180(16), 2979-2990
 

University of Rochester Medical Center
601 Elmwood Avenue, Box 689, Rochester, NY 14642.
Webmaster | Last update: 5/10/2011