An Attribute Based Access Control Framework for Healthcare System

Nowadays, access control is an indispensable part of the Personal Health Record and supplies for its confidentiality by enforcing policies and rules to ensure that only authorized users gain access to requested resources in the system. In other words, the access control means protecting patient privacy in healthcare systems. Attribute-Based Access Control (ABAC) is a new access control model that can be used instead of other traditional types of access control such as Discretionary Access Control, Mandatory Access Control, and Role-Based Access Control. During last five years ABAC has shown some applications in both recent academic fields and industry purposes. ABAC by using user’s attributes and resources, makes a decision according to an access request. In this paper, we propose an ABAC framework for healthcare system. We use the engine of ABAC for rendering and enforcing healthcare policies. Moreover, we handle emergency situations in this framework.


Introduction
The principal concern of Personal Health Records (PHR) is confidentiality [1], especially when patients use commercial healthcare distributed based systems, such as Microsoft HealthVault [2] or WebMD, to maintain their health records. Access Control Mechanism (ACM) is useful for providing access policy for different types of users. However, traditional access control mechanisms, such as Role-Based Access Control (RBAC) and Identity Based Access Control (IBAC), have several restrictions in distributed based systems [3], [4]. In particular, the data owner is unable to control the information when they upload their data to the server.
Access control means the process of defining and managing which users are permitted to perform what operations on which objects in a system. Availability of resources is one of the aspects of access control that conflicts with restricting access to resources that is another perspective of access control [5]. Access control creators need to know how the organization functions work and the access requirements of the system users. In case of the high-level user restrictions, the result has at least two kinds of disadvantages. First, if the user with a valid request cannot access to seeking information, then she tries to find other ways to accessing the required recourses. Second, and more important in healthcare systems is the lack of exception case handling. Several of the access control mechanisms have been proposed in healthcare information systems [6], [7], [8], [9] without addressing exception or emergency handling. However, some of those have had to pass exceptions to the typical access control mechanisms to be able to satisfy the needs of their users in emergency cases. It is evident that handling of exception cases is not easy due to its effect on control over information flow in a healthcare system. The purpose of this study is to apply the concept of ABAC instead of existing current access control mechanisms, and also to address the problem of emergency cases in healthcare applications. The rest of this paper is organized as follows. Section 2 includes two subsections on background and related work. In section 3, we show an ABAC framework for the healthcare system. Section 4 describes how to manage emergency situations. In section 5, contains conclusions and future work.

Background
ABAC describes an access control model where access rights are admitted to users by the use of policies [4]. Attributes are properties that describe specific features of the subject, object, environment conditions, and requested actions that are predefined and preassigned by an owner or administrator or authority. Attributes are formed of an arbitrary section that indicates the class of information supplied by the attribute, a name, and value.
A subject is an actual entity such as a person, process, or device that by sending requests makes changes to the system's status. It could be a user, requestor, or mechanism acting on behalf of a user or requestor. In this work, we assume that subject and user have the same meaning. An object is a passive system-related entity that contains or receives information such as files, records in a table, databases, applications, networks, and domains. For the goal of this work, we assume that object and resource are synonymous.
By processing of a subject's request upon an object, the system runs a particular function, which is called an operation. Operations could be one or more of the following functions: read, write, edit, delete, author, copy, execute, and modify. The policy is the description of rules or connections that determine the set of permissible operations a subject should run upon an object in authorized environment conditions. The policies could contain the combination of the following kinds of attributes [4], [10]: User (subject) attributes, resource (object) Attributes, environmental attributes (conditions) and administrativeattributes.

RelatedWorkThe
Role-Based Access Control (RBAC) model was formally presented by David F.Ferraiolo and Richard Kuhn [11]. By using RBAC, organizations can assign users to defined role(s). Then users can obtain all the permissions of the roles of which they are the member. Roles can be generated for the various tasks in an organization and based on ability, and eligibility, users are assigned to the roles. Users are able to select other roles based on the system policy management. Roles can be given new permissions from resources, and permissions can be revoked from roles as required.
The above description has turned RBAC as a primary model of option for access control applications. However, RBAC suffers from some major problems, especially in healthcare system. First and the major weakness of RBAC is role explosion [12]. When an organization that using RBAC faces a rising number of various real-world roles it needs an increasing quantity of RBAC roles to define permissions well. In this case, handling all those roles becomes a complicated circumstance [13]. Next, RBAC gives an almost same level of access to users who have the same roles. Although RBAC is scalable and adaptable and has been implemented a lot in different applications [14], [15], [16], it is not proper for the healthcare systems [17]. As part of authorization process, PDP is the heart of the system and responsible for assessment on policies and attributes that come from PAP and PIP, respectively, to return an access control decision. In other words, it makes the access decisions by assessing the appropriate policies and attributes. The PDP should return the decision procedures based on the ACM's computational languages like XACML [18]. Of course, one of the principal duties of the PDP is to reduce the risk of collision between system polices and corresponding Meta-Polices (MP).

Access Control Architecture
Then, the output of PDP must be enforced by the next component. This function refers to the PEP. In response to a user's request, the PEP performs the appropriate access decisions that is prepared by the PDP. In this system, user could be a doctor, researcher or nurse. The result or output of PEP could either allow or deny user access to the requested protected patients' records. Packages of PDP and PEP work as authorization services and they need some information regarding user and patient's attributes as part of the input to properly perform their duties. PIP addresses this issue, and it works as the retrieval source of attributes as well as healthcare environmental data, and other data needed for policy assessment. For storing and retrieving polices in an appropriate repository, we need another function, called PAP. PAP should also be able for creating, editing, running and debugging policies and MPs by a user interface. To explain how this proposed framework can handle a user request and protect patient's privacy, we use a simple scenario as follows.
First of all, we should have the primary policy for the whole system. Consider in a hospital, doctors could have access to all patient's individual records, and nurses just have access to identity patients' information, and researchers can see statistical information only if the number of patients is greater than 50. Besides, each set of policy must have a supplementary segment that specifies requester, type of resource and action. In this case, data requester must be a doctor, nurse or researcher. Resource demonstrates clinical health data like patient's individual records that contain high-level sensitive data, and the action is the set of proper functions that data requester is authorized and permitted to do on the resource, such as read, write and execute. If all conditions mentioned in supplementary segment of the policy are satisfied by a data requester, like a doctor, then the policy set might be considered as an applicable policy.
Consider the following table that shows our example and some additional conditions in supplementary segment. Each employee in hospital has a role attribute. If the value of this role equals to doctor, nurse or researcher, then they might be able to see some results from sensitive health information.
Assume a doctor as a data requester needs to read a particular patient's record and this record has been registered two years ago (Request 1). Based on the supplementary segment in Table 1 that request satisfies all the conditions. Thus, the policy can consider as an applicable policy. On the other hand, patients can totally determine who can access to their health data and for what part of data by adding some policies. For instance, a patient just allows her doctor to have access only to her last year treatments. Also, the patient is not willing to share his health data with any researcher.
Based on the aforementioned patient policy (conditions), the Request 1 should be rejected due to the value of attributes of data requester, that cannot satisfy the patient's policy. Of course, the system must have a strategy in especial occasions to avoid conflicts. As an example, if the system receives two decisions that made by PDP at the same time on a same resource, then the system should call a particular algorithm to handle the conflict.

Manage Emergency Cases
Handling emergency situations in a healthcare system is so complicated. Consider a particular patient comes with or without an ambulance to the hospital, and there is no time for patient registering process that is essential for access control. We propose a mechanism to manage that situation called emergency access. In this case, the healthcare system provides some access to the patient's data. This grant is not only directly related to a job position or special role, but is also intended as a special permission associated directly with the particular data requester to be able to satisfy all the following conditions with her attributes.
• Data requester must be a doctor.
• The doctor must work in an emergency section.
• The doctor must be at work at the time of the request. The reasoning for this policy is that only a limited number of data requesters might be able to assign this permission, and they must be decided on their attributes not just based on the job position. Besides, there is a possibility of tracing the usage of emergency access by an administrator. Normally only a few users at emergency sections might be able to gain this permission. Although emergency access is only supposed to be applied in emergency cases, to prevent any abuse of this grant, we appended some additional conditions after assigning the permission. The conditions may modify lightly from one system to another, but the most common ones can define as follows: • If the patient sets some policies after a while, then emergency access is not valid any more.
• By using the emergency access just permit user to have access only to a subset of the available patient information, not the complete patient record. To gain access to the other parts of the record, the user has to pass some other system policies. • Information obtained using emergency access will only remain accessible for the data requester for a short period of time that can be defined based on average time needed. • Regaining access to the patient's information after a timeout is needed to satisfy all the conditions again.

Conclusion
In this paper, we have illustrated the application of ABAC as a framework in the healthcare systems. Besides, we have discussed on how this framework can manage and enforce policies to grant or deny data requesters based on their attributes. ABAC supports accommodating the unexpected users. By using this feature and applying some conditions as an emergency access policy, we have demonstrated how an emergency situation could be handled with patient's privacy protection. Although ABAC has several advantages in the healthcare systems, it is still largely in its infancy, and the list of future work and open problems are extensive. For instance, we could add some other features to address other real scenarios. Implementing the new framework with new features and check the corresponding performance are among other future directions of this work.