Towards an Access Control Model for Collaborative Healthcare Systems

Mohamed Abomhara and Geir M. Køien

Department of Information and Communication Technology, University of Agder, Grimstad, Norway

Keywords:

Access Control, Authorization, Electronic Health Records, Security, Privacy, Collaborative Healthcare

Systems.

Abstract:

In this study, an access control model for collaborative healthcare systems is proposed. Collaboration require-

ments, patient data conﬁdentiality and the need for ﬂexible access for healthcare providers through the actual

work they must fulﬁll as part of their duties are carefully addressed. The main goal is to provide an access

control model that strikes a balance between collaboration and safeguarding sensitive patient information.

1 INTRODUCTION

Healthcare services necessitate collaborative support

from multiple parties to fulﬁll the information re-

quirements of daily clinical care and provide rapid

patient care (Moonian et al., 2008). Collaborative

support is required within healthcare organizations

such as hospitals, where patient records must be

moved among healthcare professionals, laboratories

and wards, to name a few. Collaboration among

healthcare organizations is also essential for patients

being transferred from one healthcare provider to an-

other for specialized treatment. Such collaboration

within or among healthcare organizations has been

shown to provide cost-effective healthcare services

(Alshehri and Raj, 2013). However, collaboration and

information sharing raise security and privacy con-

cerns (Gajanayake et al., 2014). Patient records con-

tain sensitive information that calls for appropriate

access control mechanisms to ensure conﬁdentiality

and protect integrity of data as well as ﬁlter out ir-

relevant information to reduce information overload

(Alhaqbani and Fidge, 2008).

Access control is deﬁned as a mechanism through

which users are permitted access to resources accord-

ing to their identities (authentication) and associated

privileges (authorization) (Hu et al., 2006). Access

control mechanisms have undergone many develop-

ments in both academia and industries in order to

meet healthcare domain needs. However, progress to

date has not been sufﬁcient to fulﬁll the security re-

quirements of a collaborative healthcare environment

(Alhaqbani and Fidge, 2008). The majority of mod-

els, such as Role-Based Access Control (RBAC) (Fer-

raiolo et al., 2001) and Attribute-Based Access Con-

trol (ABAC) (Hu et al., 2014) for instance, help re-

strict medical records to users based on certain roles

and attributes, but sensitive information can still be

compromised by authorized insiders (Alshehri et al.,

2013; Alshehri and Raj, 2013; Ferreira et al., 2007).

Such models and extensions have been employed in

speciﬁc applications to manage information access in

a controlled environment. Nevertheless, few stud-

ies have addressed the issue of managing informa-

tion access within the context of team collaboration

(Thomas, 1997; Georgiadis et al., 2001; Alotaiby and

Chen, 2004) and workﬂow (Le et al., 2012; Russello

et al., 2008). This study, proposes an access con-

trol model that is secure, ﬂexible, easy to manage,

and supports cooperative engagements. Our focus is

mainly on collaborative activities that are best accom-

plished through organized groups of healthcare practi-

tioners within or among healthcare organizations with

the objective of accomplishing a speciﬁc work (treat-

ment of patient’s case).

1.1 Collaboration and Secure Sharing

of Healthcare Data

Healthcare providers deal with large amounts of sen-

sitive healthcare records which are shared and collab-

oratively used among different healthcare practition-

ers (Fabian et al., 2015). Collaboration occurs when

a healthcare provider such as primary care doctor re-

quests help from another healthcare provider to treat

a case. Figure 1 provides an example scenario of col-

laboration and sharing of healthcare data.

In this scenario, a 7-year old patient visited his pri-

mary care doctor with high body temperatures. The

Abomhara, M. and Køien, G.

Towards an Access Control Model for Collaborative Healthcare Systems.

DOI: 10.5220/0005659102130222

In Proceedings of the 9th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2016) - Volume 5: HEALTHINF, pages 213-222

ISBN: 978-989-758-170-0

213

Patient

Primary care

doctor

Discharged

General

medicine ward

Infectious

diseases

consultation

Cardiology

consultation

Visit

Admit to

Request

consultation

Transfer

Share PHRs

PHRs : Patient Healthcare Records

Share PHRs

Figure 1: An example scenario of collaboration and sharing

of healthcare data.

patient was quickly examined by the primary care

doctor and the cause of fever could not be found.

The patient was admitted to the general medicine

ward, where he was reassessed by the attending physi-

cian who requested some routine blood tests. Upon

admission, the attending physician subsequently re-

quested an infectious diseases consultation because

the patient begun to develop a skin rash. The infec-

tious diseases team investigated further and decided

to consult the cardiology team as they were concerned

about Kawasaki disease. The patient was immediately

transferred to the cardiology ward. Eventually, the pa-

tient made a substantial recovery and was transferred

back to general medicine ward. After spending a few

more days in the hospital, the patient has recovered,

then he was discharged, and advised to see his pri-

mary care doctor for follow-up.

In such group consultation, it is noticed that, sev-

eral healthcare professionals are involved in various

roles to provide patient care. That includes primary

care doctors, general physicians and specialists such

as the infectious diseases team and cardiologists. Ev-

ery participant needs to obtain the medical records

they request based on the health insurance portabil-

ity and accountability act (HIPAA) minimal disclo-

sure principle (Zhang and Liu, 2010; Fabian et al.,

2015). Therefore, sharing and accessing healthcare

records with efﬁcient coordination between health-

care practitioners to perform collaborative work is a

critical function in access control models (Alotaiby

and Chen, 2004). The main concern is about los-

ing control over the sensitive healthcare records while

sharing them with multiple parties. Many researches

(Shen and Dewan, 1992; Thomas, 1997; Rubio-

Medrano et al., 2013) have developed access con-

trol models to support collaborative requirements by

deﬁning a set of rules in the subject, objects and

access rights dimensions. However, these models

are general and quit complex. Additionally, they do

not present an applicable solution for collaborative

healthcare system.

The remaining parts of this study is structured as

follows: section 2 discusses the insider threat prob-

lem in the health domain and presents an overview of

the existing access control models. In section 3, the

proposed access control model is introduced. Conclu-

sions and future works are suggested in section 4.

2 BACKGROUND

In this section, a brief overview of the insider threat

problem in the healthcare domain is presented along

with existing access control models and their pros and

cons with respect to health systems.

2.1 Insider Threat

As shown in our scenrio (Fig.1), healthcare services

need the collaborative support of multiple healthcare

professionals and administrators in order to deliver

rapid patient care. Therefore, multiple users (e.g.

doctors and nurses) may require access to patient in-

formation to perform tasks. For this reason, insider

abuse or misuse of privileges (Probst et al., 2010) can

be a threat to patient information and a liability for

health care providers. One of the main causes of in-

sider threats in collaborative healthcare is information

leakage, which emerges when a supporting party is

granted access beyond what is actually required (Fig-

ure 2 (a)). For instance, in treating a patient case, the

main practitioner consults a specialist from another

department. In doing so, improper information ac-

cess might occur if the specialist (e.g. cardiologist)

obtains more permission than required. The key to

solving this issue is to minimize the discrepancy (Fig-

ure 2 (b)) between the granted access and the required

access based on what is really needed.

Required

Granted

Required

Granted

Improper

Access

Figure 2: (a) Granted vs required information access and

(b) Minimization of access discrepancy.

2.2 Access Control Models

Research in security area has made every possible ef-

fort to address security challenges related to autho-

rization and access control. In this section, exist-

ing access control models are discussed, and their

strengths and weaknesses are identiﬁed with respect

to healthcare systems.

HEALTHINF 2016 - 9th International Conference on Health Informatics

214

2.2.1 Discretionary Access Control (DAC)

DAC (Hu et al., 2006; Kayem et al., 2010; Sama-

rati and Di Vimercati, 2001) deﬁnes access control

privileges based on the subject’s identity and the ac-

cess rules in place. It determines whether the subject

can or cannot execute particular actions on speciﬁc

resources (objects or ﬁles). DAC allows the subject

to own resources and for ownership to be transferred

to another subject (Majumder et al., 2014). Although

DAC policies tend to be ﬂexible and are widely de-

ployed, DAC has several drawbacks when utilized in

healthcare systems (Alhaqbani and Fidge, 2008; Ga-

janayake et al., 2014). First, ownership and permis-

sion updating is not scalable, as the number of users

and medical records are continuously growing. Sec-

ond, DAC policies do not provide high security assur-

ance, because granting read access is transitive and,

DAC allows data to be copied from one resource to

another, which can result in unintentional information

ﬂow in a system (Hu et al., 2006).

2.2.2 Mandatory Access Control (MAC)

In MAC (Samarati and Di Vimercati, 2001; Hu et al.,

2006; Majumder et al., 2014), a subject cannot change

the access rights to objects because access control

policy decisions are made by a central authority. Un-

like DAC, MAC controls information ﬂow to en-

sure information conﬁdentiality and integrity (Kayem

et al., 2010). However, enforcing MAC policies in

healthcare systems is often very difﬁcult due to the

vast numbers of users, the wide range of data types,

and the requirements to give patients control owner-

ship of their own medical records.

2.2.3 Role-based Access Control (RBAC)

RBAC (Ferraiolo et al., 2001) allows organizations to

enforce access policies based on subjects’ roles (job

functions) rather than users or groups, as shown in

Figure 3.

Subject

Role

Subject Assignment

Operation Object

Permission Assignment

Permission

Activity

Attribute

Task

Collabrative

Context

Criteria

PolicySpace-time

Role

Discretionary

Environment

Request Permission

Figure 3: Overview of the RBAC model.

Subjects (users) are assigned roles (e.g. patient,

doctor, or nurse), permissions (or access rights) are

then grouped based on the roles. Access to resources

(medical records in this case) is restricted to au-

thorized individuals according to the assigned roles.

RBAC has a number of advantages, including ﬂex-

ibility in terms of permission administration man-

agement, since roles can be updated without updat-

ing permissions for every user. Moreover, the use

of role hierarchies provides additional advantages, as

one role may implicitly include operations associ-

ated with another role. Also, the separation of du-

ties (SoD) principle ensures that no user is allowed

to execute two roles simultaneously. Although the

RBAC model has several advantages, it also has dis-

advantages. That is why it is not efﬁciently imple-

mented in healthcare environments. Insider threats

are a common problem faced by healthcare systems

due to RBAC’s lack of granularity (Alshehri and Raj,

2013). Roles are not sufﬁciently granular to restrict

data access to only the right (authorized) subjects.

For example, consider a role that is associated with

a set of permissions. Any subject in this role would

be allowed the permissions associated with this role

(Alshehri et al., 2013). Furthermore, RBAC does

not consider healthcare provider workﬂow (Russello

et al., 2008) nor separate task from role. Various

types of tasks with different access control character-

istics are dealt with in the same manner (Oh and Park,

2003).

2.2.4 Attribute Based Access Control (ABAC)

In ABAC (Hu et al., 2014), permissions to access the

objects are not directly given to the subject. It uses

attributes of the subject (e.g. name, age or role in

organization) and attributes of object (e.g. metadata

properties) to provide authorizations as shown in Fig-

ure 4. The permissions in ABAC depend on a com-

bination of a set of attributes and their relative values

(Ubale Swapnaja et al., 2014).

Subject

Policy Decision

Engine

Operation Object

Permission

Authorization

Figure 4: Overview of the ABAC model.

ABAC overcomes the user role assignment prob-

lem exist in RBAC and focuses on the attributes of

a user requiring to grant access. It is a very ﬂex-

ible model that is considerably easier to administer

than RBAC. However, higher ﬂexibility comes with

Towards an Access Control Model for Collaborative Healthcare Systems

215

higher complexity due to the speciﬁcation and main-

tenance of the policies. The number of subjects and

objects in healthcare systems increases dynamically.

This requires maintaining database which contains all

attributes in same format (Verma et al., 2012).

2.2.5 RBAC Extensions

The strength of RBAC lies in its manageability. It is

fairly easy to assign authorization to users based on

their roles. Unfortunately, RBAC alone does not suf-

ﬁce to handle various constraints that are required in

diverse domains. RBAC has been broadly extended

to support diverse domains in data authorization man-

agement with various constraints. Extensions in-

clude task-role based (Oh and Park, 2003), team-

based (Thomas, 1997; Georgiadis et al., 2001), con-

textual role-based (Motta and Furuie, 2003), context-

aware (Kouﬁ and Vassilacopoulos, 2008) and so forth

(Tolone et al., 2005). However, these extended mod-

els would add additional complexity to healthcare

systems because they still face some problems (Moo-

nian et al., 2008). Granularity and manageability are

inversely proportional to one another. Higher gran-

ularity in security invariably implies more complex

management. This is apparent in attribute-based ac-

cess control (ABAC), which offers higher control or

granularity at the expense of lower manageability. On

the other hand, role-based access control (RBAC) ev-

idently provides lesser granularity for better manage-

ability. To combine the strengths of both approaches

without being hindered by their limitations, bilayer

access control (BLAC) has been devised (Alshehri

et al., 2013; Alshehri and Raj, 2013). BLAC enforces

a two-layer access control that initially applies RBAC

and ABAC. The model uses the concept of pseudo-

role, which is deﬁned as a set of static attributes of

subjects. A pseudorole is not a real role, which is

traditionally deﬁned as a job function. Subjects’ at-

tributes are categorized as static attributes (when at-

tribute values typically do not change) used to gen-

erate pseudoroles and dynamic attributes (when at-

tribute values change frequently). Static and dynamic

attributes are used in policies to constrain pseudoroles

(Alshehri and Raj, 2013).

Despite the advantages offered by BLAC, it is

not exclusively tailored for collaborative healthcare

system. BLAC focus has not been placed on sup-

porting collaboration and coordination work. Thus,

an additional policy can be deﬁned at the 2

layer

of BLAC to ensure more secure interaction between

cooperating parties. Although secure collaboration

is achievable via intricate policy management, doing

this would basically reduce the approach to ABAC.

Thus, the issue of low manageability may resurface

when using BLAC to secure a collaborative effort.

3 PROPOSED ACCESS CONTROL

MODEL

To alleviate the aforementioned limitation of BLAC

and satisfy access control requirements for collabo-

rative healthcare systems, work-based access control

(WBAC) model is proposed (Figure 5). In the pro-

posed model, a secondary RBAC layer, with extra

roles extracted from team work requirement, is added

to BLAC to manage the complexity of cooperative

engagements in the healthcare domain. Policies re-

lated to collaboration and team work are encapsulated

within this coordinating layer to ensure that the at-

tribute layer is not overly burdened. The main con-

cepts of our model are:

1. Subjects are assigned to pseudoroles and/or team

role (section 3.1) and objects are associated with

WBAC policies; main policy and collaboration

policy.

2. Access control is performed on three-step evalua-

tion procedure; pseudoroles evaluation, team role

evaluation and rule examination (section 3.3).

BLAC

First layer

RBAC

Second layer

ABAC

WBAC

First layer

Primary

RBAC

Second layer

Secondary

RBAC

Third layer

ABAC

Complex

coordination

of policies

at the

attribute level

Restructuring

Figure 5: BiLayer Access Control and Work Based Access

Control.

In this study, ”work” is deﬁned as an entity com-

prising a collection of elements that interact with one

another for a particular outcome to be achieved suc-

cessfully. As shown in Figure 6, the fundamental idea

is that work itself demands completion, and it is di-

rectly linked to the patient, context, personnel and

goal.

A goal is directly linked to an objective and an

objective is broken down into a set of tasks. The

difference between a goal and an objective is that, a

HEALTHINF 2016 - 9th International Conference on Health Informatics

216

Patient

Context Work Personnel

Time

Long-term

goal

Role

Objective Purpose

Task (k)Task (1) Task (n)

Workflow

Resource Policy

Figure 6: Work Model for Collaboration.

goal consists of long-term aims that need to be ac-

complished (e.g. treatment of patient) and an ob-

jective comprises of concrete attainments that can be

achieved by following a certain number of steps. Per-

sonnel in the collaboration will have their own roles.

In performing a certain task, personnel must access

resources that are governed by policies.

3.1 Team Role

Team is deﬁned as a collection of participants in spe-

ciﬁc role with objective of accomplishing a speciﬁc

work (Thomas, 1997). Each team has a responsible

team manager. Any of the participants joining a team

shares a common goal and may share a default set of

permissions for their cooperative work. The notion of

a team role is used to restrict access permissions to

those individuals who not only have the right organi-

zational roles but also are associated to the task via

team membership (Wang, 1999).

Regarding the process of collaboration and team

work, access control model must be able to provide

an efﬁcient and secure platform for people to work

together in a hospital without being deterred by re-

strictive enforcement of access control policies (Le

et al., 2012). This can be a rather delicate situation

to handle, given the fact that the ﬂuidity of team-

work within the medical domain is often incongru-

ent with technological security. To demonstrate this

notion, we consider a scenario (section 1.1) involv-

ing four medical practitioners who are working to-

gether on a patient’s case. For the sake of securing the

patient’s private (sensitive) data (e.g. mental illness,

etc.), the collaboration must be clearly deﬁned. By

default, only the main practitioner should be aware

of the patient’s personal information (need-to-know

principle). The three other medical practitioners with

supporting roles are given information based on their

contributing roles. In order to achieve this, it is imper-

ative to determine the ﬁner roles of each team mem-

ber. The team role of each member will subsequently

determine the extent of access given. For instance,

if the supporting party is included solely for consul-

tation purposes concerning the disease, only informa-

tion essential for diagnosis is provided. It is not neces-

sary to allow perusal of personal information related

to the patient. In this way, improper access to the pa-

tient’s sensitive information can be prevented.

Hospital personnel roles are often simplistically

split into medical practitioners, nurses and adminis-

trators. However, their roles in a team can be further

categorized using the team role theory (C

ordoba and

Piki, 2012). This theory contends a total of nine roles

per group, which are classiﬁed into thought, action

and management. For the purpose of this research,

they are rephrased and illustrated in Figure.7.

Role

Action

CheckerDoer Motivator

Management

NetworkerCoordinator Mediator

Thought

Evaluator

Thinker

Mentor

Figure 7: Taxonomy of Team Role.

Thought denotes a role that is dominated mostly

by thinking. To be a successful thought collabora-

tor, the person may need to understand the medical

predicament in detail without necessarily knowing the

patient. A worker in this role could be involved in de-

vising strategies to confront particular medical enig-

mas. Thus, a cardiology specialist may offer his/her

expertise regarding the best practices of performing a

heart transplant on a child without being involved in

the actual operation.

Action, as the labeling suggests, signiﬁes being

involved in task-related collaboration, such as meet-

ing the patient for a medical check-up. Having an

action role usually implies close interaction with the

patient. Nevertheless, discretion is still feasible with

care. For instance, an anesthesiologist needs to only

know the patient’s physical characteristics to prepare

anesthetic. Who the patient is, or where the patient

lives is not relevant to completing this task.

The management category comprises personnel

Towards an Access Control Model for Collaborative Healthcare Systems

217

who are mostly involved in managing others. These

types of collaborators are adept at coordinating team-

work that is susceptible to social or psychological

challenges. For example, in conﬂict management,

they may have to resolve series of opposing diagnoses

made by medical practitioners and that may otherwise

escalate into serious altercations. In this regard, such

personnel’s need for information is inwardly oriented.

They have a greater need to know personal informa-

tion about others working at the hospital rather than

of patients.

3.2 Work-Based Access Control

Work-based access control (WBAC) combines the

pseudorole in BLAC (section 2.2.5) and team role to

enable a multilayered role facility that is driven by

collaboration. Merging (Figure 8) is done by sim-

plifying the inherent classiﬁcation of team roles into

four elementary roles, i.e. the main, thought, action

and management roles. Here, collaborative team roles

are combined with the main role and are placed in the

same group. This way, access control is enforced with

superior ﬂexibility and it promotes abstraction of the

collaborative characterization of access control from

the main ﬂow. This ensures more manageable im-

plementation as a whole. Process wise, the original

BLAC procedure is enhanced with an added decision

mechanism that provides an alternative route for par-

ties beyond the normally established policy.

Pseudorole

Team Role

Merging

Main

Collaborative

Thought

Action

Management

Pseudorole

Team Role

Main

Management

Action

Thought

Role

Figure 8: Merging of Pseudorole and Team Role.

Multiple role layers (Wen et al., 2009) segregate

access validation into two modes. Veriﬁcation is done

sequentially, whereby normal validation in BLAC

gains precedence over WBAC. In other words, the

pseudorole is validated ﬁrst, followed by team role

validation. Separating the roles is a delicate agenda

as the integrity of access control during collaboration

must be guaranteed.

consider the following scenario to appreciate the

limitation of BLAC in managing problems potentially

arising with regard to collaborative work. Suppose a

physician from the primary care unit requires the help

of another physician from the oncology department.

In the policy prior to collaboration (Figure 9), only

the physician in the primary care department has ac-

cess to reading the object or resource. Therefore, any

access request by the oncology department physician

would be denied.

The policy deﬁned in Figure 9 can be visual-

ized better by studying the decision logic and pro-

cess in BLAC (Figure 10). The access decision en-

gine always checks the pseudorole’s validity ﬁrst. The

physician from the oncology department would have

to pass the initial validation for being a physician.

However, when the engine discovers that the physi-

cian’s department is not primary care, access consid-

eration halts immediately. In order to solve this prob-

lem, BLAC recommends a modiﬁcation to the origi-

nal policy. A possible modiﬁcation that allows an on-

cology department physician to read data created by

the main, primary care physician, is shown in Figure

11.

To appreciate the limitation of BLAC in managing the issues that may emerge with

regard to collaborative work, consider the following hypothetical scenario. Supposed

that a physician from the primary care unit is requiring the help of another physician

from the oncology department. The policy prior to the collaboration is given below

(Figure ). In this policy, only the physician in the primary care department is given

accessed to reading the object or resource. Therefore, an access request made by the

physician from the oncology department would be denied.

<(subject.provider = “physician”) AND

(subject.department = “primary care”)AND

(subject.hospital = “st mathew”)

</pseudorole>

<rule>

</rule>

</policy>

Figure : Original Policy Prior to Collaboration

The policy defined above can be visualized better by studying the decision logic and

its process (Mourad & Jebbaoui, 2015) in BLAC (Figure ). The access decision

engine would always check the validity of the pseudorole first. The physician from

the oncology department would pass the initial validation because he is a physician.

However, when it discovers that the department of the physician is not primary care,

the access consideration is halted immediately. In order to solve this problem, BLAC

recommends the modification of the original policy.

Figure 9: Original Policy Prior to Collaboration.

At ﬁrst glance, the policy seems valid. It now of-

fers access to a new department called oncology. En-

abling proper access to the object based on the collab-

orator’s subject ID is somewhat complicated. It is dif-

ﬁcult to deﬁne the implications of collaboration on the

rule itself because it is structured by subject, object,

action and environment. Therefore, a new attribute is

introduced known as the ’collaboratorId’. This new

collaboratorId attribute should be enforced only on

two conditions: the objects are created by the physi-

cian and are necessary for collaboration. However,

HEALTHINF 2016 - 9th International Conference on Health Informatics

218

Access request

Pseudorole

validation

valid?

Rule

examination

valid?

Access

granted

Access

denied

Yes

Policy

Difficult to manage length of

collaborative access (e.g. based

on dynamic time) . Also may

inflate original policy

Complete termination of access

consideration if valid pseudorole

is not available

Figure 10: Flow of BLAC for Invalid Pseudorole.

this is a rather tedious process because it involves the

additional task of security management. For conve-

nience, suppose that all objects created by the physi-

cian in the primary care department are updated with

the collaboratorId. Updating the objects with collab-

oratorId implies that the oncology department physi-

cian can now read every object created by the former

physician. This is true regardless of each one’s pur-

pose in the collaboration. Thus, if a conﬁdential ob-

ject is created by the primary care physician for the

purpose of a crime investigation, it is visible to the

collaborating oncology physician as well.

Apart from difﬁculty controlling the scope of ac-

cess, employing BLAC for collaboration can also be

a source of additional complexity in constructing the

rules of a policy. It is worth noting that the modiﬁ-

cation requires two changes. The ﬁrst change is done

to the pseudorole and the second to the object of the

rule, which is not desirable. It is better to minimize

the changes.

In addition to the aforementioned dilemmas, an-

other issue must be addressed. Controlling the length

of collaboration is also a cumbersome endeavor. For

instance, in limiting the collaborating party’s access

based on the time factor, the rules must be modi-

ﬁed intricately since time is fundamentally dynamic.

If not performed with care, access could be tem-

porally extended beyond necessity. Given the con-

straints faced by BLAC in managing collaborative ac-

cess control implementation, a more dynamic policy

with dual inclination is proposed as shown in Figure

12, whereby the normal policy of enforcing access

control is contained within the main policy. On the

other hand, any policy that mediates resource sharing

is covered by the collaboration policy. This way, bet-

ter access control management is achievable.

Below is the possible modification that allows a physician from the oncology

department to read the data created by the main physician in primary care (Figure ).

<(subject.provider = “physician”)

AND

(subject.deparment = “primary care”)

AND

(subject.hospital = “st mathew”)

</pseudorole>

<rule>

</rule>

</policy>

<(subject.provider = “physician”)

AND

(subject.department = “primary care”

OR subject.department=”oncology”)

AND

(subject.hospital = “st mathew”)

</pseudorole>

<rule>

object.collaboratorId=subject.Id>

</object>

</rule>

</policy>

Figure : Modified Policy Due to Collaboration

Figure 11: Modiﬁed Policy Due to Collaboration.

Certain concerns may arise with a dual policy in

the access control model, the most apparent of which

would be priority. For instance, in situations where

one policy opposes the other, which would dominate?

It is therefore clearly deﬁned that when two policies

are in conﬂict, the main policy is always given the

highest priority, regardless of context.

Subject

Environment

Object

Policy

Main policy

Collabration

policy

Figure 12: Dual Policy in WBAC.

3.3 Flow model of WBAC

Similar to the core process of BLAC, access request

in WBAC ﬁrst undergoes pseudorole validation as

shown in Figure 13. At this stage, the user’s pseudo-

role is compared against the one deﬁned in the policy.

In BLAC, failing this step results in the complete ter-

mination of decision logic. WBAC, however, treats

this differently. If the request fails, the resource is in-

spected further to determine whether it is part of col-

laborative work. If it is, then the team role of the user

in question is properly extracted and examined.

Towards an Access Control Model for Collaborative Healthcare Systems

219

Access request

Pseudorole

validation

valid?

Collaborative

resource

Rule

examination

Team Role

validation

Coordination

Rule

examination

valid?

Main policy

valid?

Access

granted

Collaborative

policy

Access

denied

Yes

Figure 13: Flow of WBAC.

In cases where the user possesses a valid team role

over the resource, the extent of access is determined

by the collaborative policy. This policy controls the

granting of access according to the user’s purpose

within the team. For instance, users with the action

team role receive more access to a patient’s personal

information as compared to users with the manage-

ment team role. This is because the former type of

user is in greater need of the information to perform

their job than the latter.

Complications might arise in terms of coordinat-

ing the ramiﬁcation of two different policies, i.e. the

main and collaborative policies. Considerable con-

cern would also pertain to whether a request initially

denied by the main ﬂow should be granted access by

an alternative ﬂow. In resolving this, it must be noted

that the nature of collaboration is never free from

risk. Sharing information always entails compromise

to certain parts of security. As such, it is impossible

to negate the danger altogether.

As mentioned in earlier sections 2.1, a realistic

way of handling collaboration risk is to minimize the

discrepancy between the granted and the required ac-

cess. This is where the coordination element becomes

vital. The delimiting principle of access restriction

must be balanced with the necessity for information

distribution. Excessive restriction can hamper coop-

eration while too much freedom can entirely defeat

the purpose of security.

A way of simplifying conﬂict resolution between

competing policies is to utilize a tabular representa-

tion in organizing shared resources and team roles.

Each resource contains four options that reﬂect the

team role involved. The options should not be exclu-

sive by nature and the administrator can select none

or all. Zero selection implies that the resource is not

open to collaborative access and can only be accessed

based on user-related pseudoroles and rules. In con-

trast, complete selection means the resource is pub-

licly available to everyone collaborating.

To concretize the possibility of using tabulariza-

tion in deﬁning a collaboration policy, it would be

useful to consider the illustration below (Figure 14 ).

Here, the collaborative resources required for work

are enumerated in table form. Each shared resource

is tied to the set of collaborative roles or team roles

that can access it. In effect, the selected roles will de-

termine the extent of collaborative access. Note that

the collaborative role for a particular resource should

be set in accordance with its purpose (Figure 15). A

patient’s personal information is vital to the main col-

laborator and those with an action team role. How-

ever, medical information, which might be less sensi-

tive and fundamental to treatment than personal infor-

mation, should be made accessible to most team roles

except the people role.

Collaborative Resource

Collaborative Role

Resource (1)

Main Management Action Thought

Resource (N)

Main Management Action Thought

Collaborative Resource

Collaborative Role

Patient personal information

Main Management Action Thought

Patient medical information

Main Management Action Thought

Staff personal information

Main Management Action Thought

ABAC

In ABAC, permissions to access the objects are not directly given to the subject. It uses attributes

of the subjects such as subject’s name, age or role in organization and attributes of objects such

as metadata properties to provide authorizations. The permissions in ABAC are depending on the

combination of set of subject and object’ attributes and their relative values.

ABAC overcome the user role assignment problem which exist in RBAC and focuses on

the attributes of a user required to grant access. It very flexible model that is considerably easier

to administer than RBAC. However, higher flexibility comes along with the higher complexity

due to the specification and maintenance of the policies. The numbers of subjects and objects in

healthcare systems is dynamically increased, which require maintained database containing all

attributes in same format.

Figure 14: Simpliﬁcation of Collaborative Role into Tabular

Form.