Proximity Based Access Control inSmart-Emergency Departments

Abstract— An automated access control model for smarthospital emergency departments (ED) is possible throughdecisions based upon the proximity of users to resources.The notion of proximity of a resource is dependent uponmany factors, including: the three-dimensional accuracy ofthe positioning system employed, geometry of the physicalworkspace, the electromagnetic environment and accesscontrol policies for the resource.

In this paper, we propose a proximity based automatedaccess control (PBAC) model for smart-ED environments.The goal is to develop a context-aware and trustworthysmart-ED that improves the existing ED work-flow byautomating certain mundane activities (accessing patientrecord without a password) allowing caregivers to focuson the treatment of patients. The level of access providedto the users (caregivers) is dependent upon their roleswithin the hospital and the system context. To preventany unauthorized access, we have suggested three levelsof authentication: Unauthenticated, Authentication LevelI and Authentication Level II. This authentication schemacomplements the access control model while facilitatingappropriate level of access privileges to users. Further,the access control model is dynamic and adapts itself tounpredictable events that require urgent action.

We also present a semi-formal specification for theproposed access control model in terms of policies fordifferent usage scenarios. We further validate our spec-ifications by developing a prototype for the PBAC model.The prototype was built on top a Ultra Wide Band (UWB)based positioning system whose accuracy was tested in areal ED environment.

I. INTRODUCTION

Hospital emergency departments (ED) must provideeffective and timely treatment to all patients, manytimes in an unpredictable environment. Mundane activ-ities such as data entry and retrieval often impact EDefficiency by distracting caregivers who must interfacewith multiple secured hospital information systems toaccomplish these tasks. Automating certain tasks, suchas authentication login, will reduce these distractions andallow caregivers to concentrate on treating patients [20].For example, in a smart-ED, caregivers needing access toa patients medical history can be automatically logged-in, without typing a user name or password, by virtue

of their proximity to a computer. As a result, they cancontinue patient care and review clinical data withoutbeing distracted by mundane administrative procedures.However, automating access control to information re-sources in the smart-ED poses certain security issues. Asvarious people need access to the information system or aparticular resource, the automated access control systemmust be able to distinguish between different users inclose proximity, determine their privileges and provideappropriate access.

In this paper, we introduce a mechanism for providingautomated access to resources in a smart-ED environ-ment via a Proximity-Based Access Control (PBAC)scheme. This scheme makes access control decisionsbased on the proximity of the user to a particular resourcesuch that when the user enters an established zone aroundthe resource, access is automatically granted. In orderto be effective, privileges to access a resource must behighly granular in nature - similar to user accounts inan operating system. We address this issue by usinga form of Role-Based Access Control (RBAC) [3],whereby users are assigned different roles, and basedon these roles, are granted predefined access privilegesto the resources. Therefore, when a user comes into thedefined proximity zone of a resource, access privilegesare granted based on their role within the system.

Proximity-based access has certain pitfalls in that itcould potentially allow someone (even an unauthorizedperson) access, when an authorized user is in proximitybut not currently using the resource. A malicious usercould exploit this situation by accessing the resourcewith the other authorized user’s privileges. To preventthis, the system must include authentication mechanismsto prevent users from accessing resources for which theyare not actually entitled. For example, a nurse standingby computer should not be able to gain access to adoctor’s log-in when the doctor is merely in proximityof the resource.

Authentication mechanisms should not be static andmay need to change during unusual circumstances. Un-der normal circumstances, resource access privileges arederived from the role of the user needing access. How-

Fig. 1. ED Workflow

ever, during abnormal circumstances requiring urgentaction, the process must allow for flexibility. Examplesof abnormal circumstances might be the unavailabilityof caregivers assigned to a patient or an influx of alarge number of patients in the ED as a result of adisaster. Routine access privileges (those used undernormal circumstances) may not meet the requirementsfor such situations and may even impede the ability toappropriately manage them. For example if the assignedcaregivers for a patient are not available during anemergency, then the routine access privileges would notallow access to any qualified caregiver in the vicinity ofthe patient.

Though unusual in the ED setting, this scenario showsthat with the traditional authentication mechanisms itmay not be possible to override security requirementsduring an abnormal or even disaster situation. In the restof the paper, we refer to such situations as critical eventsand the state itself as criticality. The goal of this paperis to present a Proximity-Based Access Control (PBAC)model for smart-ED environments to provide automatedaccess, to resources, at appropriate security levels (formedical professionals) in both critical and non-criticalsituations.

To implement the PBAC model we first defined thenotion of proximity of a resource by designing a spe-cific area, called proximity zone, around the resource.The shape and size of the proximity zone is designedbased on the following parameters: the three-dimensionalaccuracy of the positioning system employed, geometryof the physical workspace in the ED, the electromagnetic

environment and the access control requirements for thedesignated resource.

Once we have a concrete definition of proximity wecan provide access to resources when a user comes inthis area. However the level of access provided is notthe same for all users and to prevent inadvertent ormalicious access to resources, as a result of PBAC, wedeveloped three authentication levels: Un-authenticated(access privileges only to publicly available resources),Authentication Level I (common access privileges to agroup of users, i.e. nurses, physicians, etc.), Authenti-cation Level II (access to private user information orsecure clinical information). This authentication schemacomplements the access control model while facilitatingappropriate level of access privileges to end users. Wefurther extend the aforementioned access control modelto include criticality handling capabilities. During criticalsituations, this model adapts itself to provide a new set ofaccess privileges to users in order to manage the criticalevent.

A. Contribution

Our main contribution in this paper is to design, spec-ify and validate a proximity based access control modelfor ED environments. The proposed PBAC model en-hances the work-flow in the ED by providing automatedaccess control to the resources. Further, by incorporatingdifferent levels of authentication, the model preventsthe security pitfalls normally associated with proximitybased access control mechanisms. The proposed modelalso facilitates the handling of the critical events by

appropriately adjusting itself.To concertize the model we provide a detailed semi-

formal specification of the PBAC model with compre-hensive policies for handling both administrative andaccess control tasks within the system. The policies areadaptive enough to be applied in both normal and criticalsystem states. To validate the policies we developed aprototype with an Ultra Wide Band (UWB) based po-sitioning system. We further field-tested this positioningsystem in a functioning Level-One Trauma Center ED inthe Phoenix metropolitan area to determine its accuracywhich facilitated the determination of the shape and sizeof the proximity zone.

B. Organization of the paper

Our paper is organized as follows, Section II presentsthe motivation for this work, followed by Section IIIwhich presents the concept of Proximity Based AccessControl and its design issues. Section IV provides de-tails of the access control model by present roles andtheir management issues. Section V presents the accesscontrol policies applicable for a PBAC based system.In Section VI we present a detailed discussion on thepractical issues related to this work, followed by therelated work and conclusion in Section VII and SectionVIII respectively.

II. MOTIVATION

In this section we present the need for automatedauthentication access to resources in an ED, describeED work-flow, and demonstrate how PBAC can improveefficiency.

Patients follow certain well-defined service paths (Fig-ure 1) in the ED, but the actual path often depends ontheir presenting condition. Patients may arrive by publicor private vehicles, on foot, or by ambulance. Onceidentified as requesting emergency evaluation, patientsare logged-in, triaged by a nurse (either in a triage areaor in a treatment room) and registered at an appropriatetime. The triage process determines the priority of whenand what type of services a particular patient will need.Based on the triage assessment, patients may be sent toa waiting area or directly to a treatment room. Criticalpatients, who most often arrive by ambulance and requireimmediate medical attention, usually bypass triage andare taken directly to a treatment room or specialized areasuch as a trauma or resuscitation room. The processof tracking patients from the moment of arrival; totriage; to the waiting or treatment area; to the timethey are seen by the physician and nurse; to various

ancillary departments (such as radiology); and throughhospital admission or discharge has traditionally been acumbersome, incomplete and inaccurate manual process.Automated tracking of patients and staff throughout thisprocess holds much promise [20].

Physicians, nurses, and other caregivers often requireaccess to several data systems, each requiring a uniquelog-in process. Aside from remembering several pass-words, these log-in processes distract staff from theirnatural work-flow. Session loading and unloading mayalso detract from patient care. An access control systemthat automatically logs-in a pre-authenticated user to aresource, based on the proximity of the user to thatresource, will reduce distraction, improve efficiency andimprove patient care.

Further, caregivers tend to leave computer resourcesopen without closing their session after each use. Al-though typically the system automatically closes the ses-sion after a preset inactivity interval, patient informationis vulnerable to inappropriate access during this time.Using PBAC can eliminate this vulnerability by auto-matically closing or suspending a session immediatelyafter a user has left the vicinity of the resource.

The ED is a collaborative working environment wherethe caregivers cooperate on many different levels; there-fore access control policies need to be adapted to thesespecial requirements. For example, a resource beingactively used by a nurse should not automatically berelinquished to a doctor (even though the doctor mighthave a higher priority access). Instead, typical work-flowwould dictate that the nurse be notified on-line of thepotential need of the resource by the doctor. Off-linecommunication could then determine appropriate releaseof that resource. This process eliminates the possibilityof frequent spurious session interruptions in a busy areawhere user sessions could be pre-empted because ofinadvertent movements of other users.

III. PROXIMITY BASED ACCESS CONTROL

Proximity Based Access Control (PBAC) is a tech-nique for providing automated access to resources basedon the proximity of a user to that resource. Proximity canbe defined as a zone around the resource, within which,a user must be located in order to gain access. There arethree main aspects of PBAC necessary to determine theaccuracy of the access control automation process:

1) The design of the zones which define the proximityof resources.

2) The three-dimensional accuracy of positioning sys-tem employed to verify when a user is in the

Proximity Zone

Tier 1 Proximity zone

Tier 2 Proximity zone

Nurse IS NOT notified of approaching doctor

Doctor

Nurse

Nurse IS notified of approaching doctor

Doctor

Nurse

Fig. 2. Single and two- tiered Proximity Zone

proximity zone.3) The security privilege level of access provided to

users within proximity of a resource.The first two aspects ensure that a user only gains

access to a resource when in the correct position respec-tive to that resource, while the last enforces informationsecurity and priority of use.

A. PBAC Zones and Positioning

The determination of a proximity zone around a re-source is tied directly to the three-dimensional accuracyof the positioning system responsible for determining thelocation of the user. This accuracy of the positioningsystems depends on the electromagnetic environment andvaries dynamically over time. To compensate for errors,error contour maps could be generated for the positioningsystem over time and used to determine the accuracyof its location information. Several positioning systemsare commercially available and can be classified intothree main types: Radio frequency (RF) narrow-band, RFwith ultrasound and Ultra-Wide Band (UWB). In indoorenvironments, UWB typically has better performancebecause: 1) UWB has short signal pulse making it lessvulnerable to multi-path effects; 2) The interferencenoise is normalized over the wide signal band which hasminimal effect on the Signal-to-Noise Ratio (SNR); 3)UWB operates in the 3-10GHz frequency range wherefew other devices would cause interference.

Apart from the positioning system, the proximityzones around resources are dependent on the accesscontrol policies for the resource. For example, supposethe access control policy of a resource mandates that

a nurse yield the resource to a doctor and that thesystem display an on-line notification when the doctoris approaching the resource. In this scenario the systemmust be able to predict the movement of the doctorand notify the nurse well in advance to allow comple-tion of work. A potential solution to this requirementwould be to define a two-tier proximity zone around theresource. A small inner zone enveloping the resourcewould determine the resource access while a largerouter zone (e.g. the room where the resource is located)would detect anyone (i.e. the doctor) approaching theresource. Access to a vacant resource is only grantedwhen the user enters the inner zone. However, oncelogged-in, the system could be configured to log-off theuser only after they leave the outer zone. Establishingtwo-tiered proximity zones for each resource providesfor the most flexibility when writing and revising accesscontrol policies. Figure 2 shows examples of single andtwo-tier resource proximity zones.

It should be noted that access policies of the resourceonly provide general guidelines for the design of thesmart space, while their actual shapes and sizes aredefined by the accuracy of the positioning system. Geom-etry of the space is a third factor affecting proximity zonedesign and supersedes these other requirements due toits immutable characteristics. Figure 3 depicts the inputparameters in the determination of resource proximityzones.

B. Information Access Granularity

Simply defining PBAC zones as noted above is notsufficient to manage multiple users with varying degrees

of security access. Obviously for any given resource,people will have differing privileges. In the examplefrom the previous section, the nurses session is closed byrelinquishing the resource and the doctor is automaticallylogged-in. But the doctor may not be subsequentlylogged-off as long as they remain within the larger tier-2 zone thereby leaving the system open to inadvertentor malicious access by others. A similar scenario mayoccur if the doctor is in the proximity of the resource,but does not really intend to access it. To address thisissue, we suggest three authentication levels as follows(Figure 4):

1) No-Authentication: User access is restricted topublicly available data. For example, bulletin an-nouncements, Internet access, a masked publicview tracking board screen, etc.

2) Authentication Level-I: The user is required toperform a single challenge/response (user name)session to be granted certain privileges commen-surate with their organizational working group. Forexample, when a nurse enters the ED for the firsttime in the shift, she presents her badge (e.g.RFID badges) at a workstation to facilitate therequired challenge-response establishing Authen-tication Level-I which is then associated with thatuser tag for the remainder of the shift. The securitylevel and information available with Authentica-tion Level-I is same for all caregivers workingwithin a domain. Examples of domain includeregions within the hospital, individuals, groupsof caregivers and group of patients. Within theED, if nurses were designated as a domain, thenall ED nurses would have access to same set ofinformation when authenticated at AuthenticationLevel-I.

3) Authentication Level-II: Users accessing sensitiveinformation or documenting in the patient recordmay require a higher level of authentication. Forexample, a doctor reviewing a patients chart ora nurse documenting a patient assessment. Un-der such circumstances it may be necessary forcaregivers to undergo another challenge/responsesession to validate their credentials as a legitimateuser for these more sensitive procedures.

Depending upon local hospital or departmental secu-rity policies and procedures, varying degrees of securitycan be established for a variety of scenarios. However,for most EDs, initial authentication at the beginning ofthe shift, with either single tiered PBAC or two-tieredPBAC where the second tier is limited to a single room

to allow monitoring of log-inaccess by users should beadequate under most circumstances.

IV. ROLE MANAGEMENT IN PBAC

In our approach to PBAC, we define two main typesof roles - organizational and group. The organizationalrole is assigned to a user when they join the systemand usually corresponds to the actual position held bythe user within the organization, for example a personjoining a hospital as a doctor gets an organizational roleof a doctor. Group roles assigned to users are morespecialized in nature and are based on a specific areaor domain where the user works. For example, usersworking in the trauma resuscitation area of the ED form agroup and get assigned to a specific group role. Similarly,groups can also be created by individual patients, i.e.all caregivers for a particular patient can be classifiedas a part of a group. Therefore, each user has oneorganizational role, but may have multiple group roles.

Each resource is assigned an access control list whichis a table of possible roles (called resource-roles) andcorresponding privileges. Access control decisions cor-responding to privileges require the mapping of a usersgroup role to a resource-role. When the user (in thedomain) is authenticated at Authentication Level-II ata resource, the privileges obtained are based on the re-spective resource-role. For Authentication Level-I, eachresource generates a common set of privileges based onthe privileges of the individual resource-roles of eachuser in the domain. Figure 5 shows the scenario wherethe privileges corresponding to the resource-roles of allthe users in the domain are input into a function

�(such

as union, intersection) to obtain the common privilegesof the whole group. However, we do not define thefunction explicitly as it is implementation specific.

A. Resource Role Generation

PBAC is highly dependent upon the resource-role auser is mapped to for a particular resource. All accesscontrol decisions are made after the resource-roles aregenerated by each resource in a domain. To generateresource-roles, resources take into account the following:� The users’ group roles (group roles encompass the

privileges of the organizational roles).� System information context.Figure 6 shows access control lists maintained by a

resource and the mapping of a user’s group role to aparticular resource-role.

As mentioned, the privileges a user obtains for a re-source is also dependent upon the context of the system.

Design of Smart Zone(s) Policies

Posit

ioni

ng A

ccur

acy

Radi

o En

viro

nmen

t of

the

Are

a

Geometry of the Area

Actual Shape and Size of the Smart Zone(s)

Fig. 3. Contributing factors in determining Proximity Zone

Information context allows the system to track dynamicchanges and can be grouped into three categories: usercontext (e.g. location of the user (proximity), user’scapabilities), resource context (e.g. capability of the re-source, current load on the resource) and environmentalcontext (e.g. number of users in the proximity of aresource at a given time). This classification, thoughaccurate, is applicable only during normal operations.During critical situations, mapping group/organizationalrole to resource-roles based on these contexts may becounter-productive. For example, nurses brought in fromother hospital departments in response to a disaster maynot be granted access to resources in the smart-ED. Tomodel context information during such disaster situations(for providing appropriate resource-roles), we define aterm called Criticality.

Criticality is a measure of the level of responsivenessin taking corrective actions to control the effects of acritical event and is used to determine the severity ofcritical events. To quantify this attribute, we introducethe term Window-of-Opportunity ( ��� ), which is an appli-cation dependent parameter defining the maximum delaythat can possibly be allowed to take corrective actionafter the occurrence of a critical event. Therefore, lowerthe Window-of-Opportunity of a critical event the higherits criticality. A Window-of-Opportunity = � indicatesmaximum criticality for a critical event while a Window-of-Opportunity = � indicates no criticality.

The resource-roles assigned to a user increase as thecriticality increases (We refer to the initially mappedresource-role for a user as the base-resource-role andthe increased role as promoted-resource-role). Thepromoted-resource-role for a user is computed based on

Role based (Private - Level II authentication

required)

Domain specific (Level I authentication required)

Public (No authentication required)

Fig. 4. Authentication Levels

the level of criticality of the situation and this increasein role for a user is done irrespective of which level ofauthentication the user normally has within the system.However, to prevent instability, the promoted-resource-role does not change if the criticality remains the same ordecreases. Once the critical event has been contained, theuser’s resource-role reverts back to base-resource-role.

To summarize our model, consider the followinghospital scenarios. When a user comes in the prox-imity of a resource, the system obtains the currentcontext information and maps the user to an appropriateresource-role which allows the user to use the resourcewith corresponding privileges. In case of an emergencyhowever, patient in a cardiac arrest for example, the levelof criticality is determined, which is used to decide thepromoted-resource-role for the user.

V. ACCESS CONTROL SPECIFICATIONS

Each resource is assigned an Access Control List(ACL) which maps all possible resource-roles and theirassociated privileges. When a user comes within theproximity zone of a resource, the resource determinesthe role of this user and maps it on to a resource-role.Users can thus access resources based on the privilegesassociated with the resource-role. For the PBAC wedefine a set of policies to formalize aspects of the systemoutlined in this section.

A. Policies: Types and Implementation

In order to implement PBAC, we must define a set ofpolicies to specify the exact rules. There are two typesof policies:� Administrative Policies - Rules for defining system

administration functions, such as adding users, as-signing roles, privileges, etc.� Access Control Policies - Rules to control accessto resources within the system (i.e. the decisions toaccount for the various roles, associated privilegesand contextual information of the system at the timeof the access).

1) Administrative Policies: These are a formal repre-sentation of the administrative policies for users obtain-ing an organizational role and group role; users beingremoved from an organizational and group role; andassigning resource roles to users. Below is a defined aset of state variables that the system maintains to managethese administrative processes:��� is the set of all users in the system.� is the set of all groups within the system.�� � is the set of all possible organizational roles in

the system.��������� is the set of group roles within a group ����in the system.��� ��� is the set of tuples which stores the mappingbetween the user’s id and her organizational role( � userid,user organizational role � ) for all theusers in the system.It is formally defined below:� ���������! #"%$'&)( *�+�-,.$/�����0&

��� ������1� is the set of tuples which stores themapping between the user’s id and her group role( � userid,user group role in group � � ). It isformally defined below:����������2�3���! #"%$'&)( +�*�-,/�2�45,/$.����������6&

Adding and Removing Organizational Roles Whena user is added to the system, they are assigned an

f 7 77 7Privileges of

User 1

Privileges of User 2

Privileges of User N

Set of Common Privileges for Authentication Level I in a Domain.

Set of privileges for a resource-role of a user

Fig. 5. Generation of domain specific privileges based on privilegesof individual group roles in a group

organizational role based on the work perform (or willperform) within the system. Algorithm 1 specifies thisprocess for a user, who is assigned an organizationalrole. This process can be carried out only by the sys-tem administrator. Similarly, Algorithm 3 specifies theremoval of the organizational role of a user.

Adding and Removing Group Roles Algorithms 2and 4 specify the addition and removal of group role ofa user. The user needs to be a part of the system (i.e.in the set U) before she can be added to any group.This operation can also be only executed by the systemadministrator.

2) Access Control Policies: When a user is in theproximity of a resource, they are given access to itbased on the following access control policies. All thesepolicies have been defined for a single tier proximityzone, extensions to multi-tiered zones is trivial. When auser comes within the proximity zone of a resource theyare logged onto the resource. The function 8:9';!8:< � =?> ; isused to determine the appropriate role for the user andperforms the following functions:� Maps the user’s group role to the appropriate

resource-role.� Generates the resource role for all the users inthe group using a function

�(to provide privileges

corresponding to the Authentication Level-I).The function @ � then maps the returned resource role

to appropriate privileges. The function A�BDC%;:EGF ��HI"KJ��returns true when a user H enters the zone J of aresource, while the function LNM0@ O ��HD� stores the currentprivileges of the user H . When the user leaves the zone J(function A P� C%F ��H#"KJ�� returns true) of a resource PBACof the user becomes empty ( Q ). The Algorithm 5 defines

Algorithm 1: Adding User to an Organization and Assignment of an Organizational RoleFunction Name : RTSTS � FU;!E � EWVAttributes : H�� Set of Users, �YX6Z\[2]_^ , =`� Set of Organizational Roles

1: if ( �a=`�����N�D,*��H+�+� �D, 8:9';!8:< � =?> ; �b�cXKZ%[2]_^'�ed�fc$ FU@gSGh � B ) then2: �idj�-k��!H#&l,���� ��dj��� �5km�!H#"\=T&3: end if

Algorithm 2: Adding User to a group number iFunction Name : RTSTS � FU;!E EKnAttributes : H�� Set of Users, �YX6Z\[2]_^ , V � Set of Group Roles, �2� Set of Groups

1: if ( ���l����o,+� V �m��N�o,���H4�+���D, 8:9P;p8q< � =?> ; �b�rX6Z\[2]_^D"K�edifc$ F ) then2: ����������edj����������Ik��!H#" V &3: end if

Algorithm 3: Remove User from OrganizationFunction Name : EG;:h =Ws ; � FW;:E � EWVAttributes : H�� Set of Users, �YX6Z\[2]_^

1: if ( 8:9P;p8:< � =W> ; �b�cXKZ%[2]_^o"K�ed�fc$ F ) then2: if ( ��H4�+���D,*�ut' 4�+� ��� FGvwC Hm�x D� ) then3: ��� ��dj��� �zy{�! #&G"q�id|�}y{�! #&4: end if5: if ( ��������#,*�ut'$.�4� �������� F~vwC�v H+��$�� ) then6: �����������dj� ������1�ry{�!$'&7: end if8: end if

Algorithm 4: Remove User from GroupFunction Name : EG;:h =Ws ; � FW;:E E�nAttributes : H�� Set of Users, �YX6Z\[2]_^

1: if ( ���l����o, 8:9';!8:< � =?> ; �b�cXKZ%[2]_^o"K�2difc$ F ) then2: ����������edj����������ey{�!$P& , t'$.�+���������� F~vwCKv H+�x$3: end if

Algorithm 5: Single User in Proximity to Unoccupied Resource1: Scenario: User enters the proximity of a resource2: if ( ANBDC1;!E�F ��H#"KJ�� ) then3: L�M�@ O ��HD�Yd @ ��� 8:9';!8:< � =?> ; ��H��%�4: end if1: Scenario: User leaves the proximity of a resource2: if ( A P� C%F ��HI"KJ�� ) then3: L�M�@ O ��HD�Yd Q4: end if

Algorithm 6: Single User in Proximity to Occupied Resource1: if ( ANBDC1;!E�F ��H��)"KJ��o, O = BDC�R � B#F ��HI�?"KJ��D,.>a= V =WH C � B � C ��Hc�p� ) then2: L�M�@ O ��Hc�p�ed Q3: L�M�@ O ��H��G�ed @ ��� 8:9';!8:< � =?> ; ��H��G�%�4: end if

Algorithm 7: Multiple Users in Proximity to Unoccupied Resource1: Policy: Choose a random user2: if ( ANBDC1;!E�F ��Ho�G"KJ�� ) then3: 8:9 = FW;:B H FW;:E d�� RTBoS ��H#�W�4: L�M�@ O � 8:9 = FW;:B H FW;:E �Yd @ ��� 8:9P;!8:< � =?> ; � 8:9 = FW;:B H FU;!E �%�5: end if1: Policy: Choose the user who is closest to the resource2: if ( ANBDC1;!E�F ��Ho�G"KJ�� ) then3: 8:9 = FW;:B H FW;:E d O >�= FW;pFpC ��H#�W�4: L�M�@ O � 8:9 = FW;:B H FW;:E �Yd @ ��� 8:9P;!8:< � =?> ; � 8:9 = FW;:B H FU;!E �%�5: end if1: Policy: Choose the user who logs in first2: if ( ANBDC1;!E�F ��Ho�G"KJ�� ) then3: 8:9 = FW;:B H FW;:E d A�R~E >�� ;pFpC �a>�= V � B � B � C ��H#�W�%�4: L�M�@ O � 8:9 = FW;:B H FW;:E �Yd @ ��� 8:9P;!8:< � =?> ; � 8:9 = FW;:B H FU;!E �%�5: end if

the function of automatic user login and logout on aunused resource. If another user ( H�� ) enters in the zone J(see Algorithm 6) of a resource when another user HI� isaccessing it( O = BDC1R � B#F ��Hc�?"KJg� ), then HI� has to explicitlylogout ( >a= V =WH C � B � C ��Hc�p� ) before H�� can login.

Algorithm 7 presents the scenario where multipleusers enter the zone J at the same time ( A�BDC%;:EGF ��Ho�G"KJ�� ),then the policy dictates giving access in three ways:randomly, to the user who is closest to the resource,or whoever requests of the resource first. When a userleaves a resource, the system checks to see how manyother users are in the proximity and uses one of the threeaforementioned techniques to give system access to theuser.

3) Criticality Awareness: The aforementioned prox-imity based access control policies are sufficient whenthe system is working in a normal manner. Howeverduring emergency scenarios, they may not be sufficientas explained in the 4.1. To handle these critical eventshigher privileges may need to be assigned to users [onspecific resources] to be able to control the emergency.The required level of access is provided in our systemby promoting the resource-role of the user on specificresources. The initial resource-role (mapped from theuser’s group role) assigned to the user is referred toas the base-resource-role while the promoted one iscalled the promoted-resource-role. This whole process ofincreasing access privileges for containing critical eventsis called role promotion. In our policy specifications,the function 8q9';!8:< � =?> ; abstracts the idea of generat-ing appropriate roles for both critical and non-criticalsituations.

In our previous work [19] we present a criticalityaware access control model, which provides the detailson handling criticality in access control models. We canuse the same model here to extend the PBAC to becriticality aware. We do not provide the details in thispaper, however a criticality aware PBAC will work asfollows:� The system is monitored continuously to detect the

occurrence of critical events. In case of an occur-rence, the system automatically finds appropriateuser’s who have the ability to control the effects ofthe critical event in the proximity and automaticallyprovides them with higher access (role promotion)to specific resources in the domain.� The privileges corresponding to this higher accessmay be even greater than privileges associated withboth Authentication Level I and II for the user.� As a user is being given privileges, which maynot be available during normal system state, thesehigher privileges are revoked as soon as the criticalevent has resolved, or the user has taken all possiblepreventive actions using the resource 1.� Every critical event has a window-of-opportunityassociated with it. This is the upper bound ofthe time interval during which role of a user canbe promoted. Any role promotion cannot underany circumstances exceed this value irrespective ofwhether criticality is controlled or not.

1As all possible actions have been taken with the resource, irrespec-tive of the state of criticality, it cannot be used any more, thereforeproviding higher privileges on such a resource is not required

Resource Roles

Resource Privileges

Role 1 Privileges for

Role 1

Role 2 Privileges for Role 2

Role N Privileges for Role N

Access Control List

Context

Organization/Group Role of User i Mapping Function

Fig. 6. Mapping of Group Role to Resource Role

� During the process of controlling criticality, the sys-tem maintains extensive logs of all the occurrenceswithin the system in a secure manner to be ableto detect malicious activity by a user with higherprivileges.

VI. DISCUSSION

The implementation of the access control policiesis highly dependent on the underlying positioning sys-tem. We used a commercially available UWB-basedpositioning system developed by Ubisense Inc. for ourexperiments. Our goal at this stage is two fold: 1) totest the accuracy of the positioning system in an EDenvironment; 2) to develop a PBAC application by usingthe APIs provided by the Ubisense system.

A. Positioning System Accuracy in ED

The Ubisense positioning system uses UWB RF sig-nals to locate objects equipped with Ubisense battery-powered transponder tags. Each tag periodically trans-mits UWB RF signal to the Ubisense sensors (also calledbase stations) which identify the tag and determinesits location using Angle of Arrival (AOA) and TimeDifference of Arrival (TDOA) of the signal [25]. Aminimum of 4 sensors are required for a cell that definesthe area within which objects may be tracked. One sensoris designated as the master sensor that ensures time-synchronization between all sensors (master and slaves).Further, Ubisense uses a separate control channel in the

range of 908 MHz, which is used to transmit controlmessages to the tags.

In our field test experiment, we deployed the Ubisensepositioning system in a functioning Level-One TraumaCenter ED located in a major Phoenix metropolitan areahospital. In separate experiments, we used 4 sensorsto create a tracking cell in two structurally differenttreatment areas within the ED. The following are ourobservations 2� The positioning capability of Ubisense UWB was

not affected by the industrial structural walls (metalstuds covered by industrial sheet-rock) of the ED.This was expected since non-metallic walls do nottypically affect UWB signals, but industrial struc-tural walls often found in hospitals was not assured.� The positioning accuracy decreases as sensor track-ing cell coverage area increases. A defined relation-ship between accuracy and coverage area has not yetbeen established.� In most cases, the vertical orientation of the tag (orperson carrying the tag) did not have an effect onpositioning accuracy, although this was not alwaysthe case.� Electromagnetic spectrum analysis of this ED in the900-930 MHz frequency range showed activity onlyat 915MHz and 930MHz. These do not interferewith the Ubisense control channel at 908MHz.� In our experiments with small tracking cells (350 sqfeet), the positioning accuracy was within a rangeof 2-8 inches despite the presence of small metallicobjects blocking the line-of-sight between the tagand sensors.

Based on the aforementioned experimental results,in the following sections, we discuss the design andimplementation issues of our PBAC scheme.

B. Design of Zones

One of the important aspects of our proposed PBACscheme is the design of the proximity zone aroundresources. The design of proximity zone has two aspects:1) the shape of the proximity zone mandated by theapplication and its environment (policies, geometry ofthe area), and 2) the accuracy of the positioning systemunder the ED’s radio environment. If f X��\� denotes theshape of a proximity zone and � Xb�\� is the set ofdistances from the resource to its boundary (mandated

2Due to the constant demand for treatment rooms where we wereconducting our experiments, we could only perform a qualitativestudy of the accuracy of the positioning system.

Fig. 7. All medical professionals outside the proximity of the resource

by the application), then we design the proximity zoneas follows:� The shape of the proximity zone ( f ) is left un-

changed, i.e. f�dif X��6� .� The set of distances from the resource to the bound-ary of the proximity zone ( � ) is given by � ] d��q���for all ���-� X��6� , where � is the error imposed bythe positioning system accuracy in ED.

For example, if the application mandated proximityzone as a circle with a radius of 5 feet around theresource, and � is calculated as the maximum error in thepositioning system (according to our experiments � dz�inches), then we can compute the actual proximity zoneas a circle with a radius of 5 feet and 8 inches.

C. PBAC Prototype Testing and Validation

We developed a prototype for the proposed PBACscheme, which relies on the aforementioned positioningsystem. The working of the prototype was tested onthe Ubisense tracking simulator by simulating variousscenarios of medical personnel entering and leaving theproximity of a resource. We demonstrate the prototypeusing scenarios with three users, (two doctors (Doc1 andDoctor) and a nurse (Nurse)) and a resource. Extensionsof these scenarios with large set of users and resourcesis trivial and therefore omitted for clarity.

1) Single User access: Figure 7 shows the screen-shotof the initial state of the system. In this state, no user hasaccess to the resource as they are not in its proximity.As these users move about, this situation will change ifand when a user comes within the proximity zone of theresource. Figure 9 shows one such state where the nursehas moved within the proximity of the resource while thetwo doctors have not. Our prototype uses the underlyingposition system to track the nurse’s presence near theresource and updates its Active Users list which storesthe identities of all the users within the proximity of theresource. As only the nurse enters the proximity of theunoccupied resource, access (to the resource) is grantedto her based on the Steps 2 and 3 of Algorithm 5. TheCurrent User attribute shows the name of the user whohas access to the resource (Nurse).

2) Multi-user access: However if multiple users enterthe proximity of an unoccupied resource simultaneously,there is a potential conflict with who gets access first. Asshown in Figure 8, all the three users have now enteredthe resource proximity thereby updating the resource’sActive Users list. To resolve the identity of the userwho is provided access to the resource, we randomlychoose one from the list of Active Users as given infirst condition of Algorithm 7 (lines 1-5). We could havechosen any of the three methods (random, proximity toresource and login initiative) listed without any security

lapse however this is a very application dependent issue.3) User in proximity without requiring access: So far

we have described scenarios where the assumption is thatthe user enters the proximity zone to access the resource.However, if a user is only passing through the proximityof a resource, the system needs to ensure that such usersare not logged in as it can cause a breech in the access.We address this situation at the policy level by specifyinga function A�BDC%;:EGF ��HI"KJ�� whose implementation ensuresthat only users present within the proximity zone for acertain time are provided access.

4) Temporary absence of user with resource access:It is possible that a user who has access to a resourcemoves out of the proximity zone temporarily. As theabsence is temporary, user’s session on the resourceneeds to be maintained for a preset amount of time. TheA P� C1F ��H#"KJ�� function in our policies abstracts this ideaout and ensures that a users’ session is closed only aftersubstantial absence from the proximity of a resource.

5) Authentication Issues: It should be noted that inthese scenarios, all three users are in AuthenticationLevel-I mode, and thus are granted the same set ofprivileges when they are allowed to access a resource.Therefore in the third scenario, when Doc1 is providedaccess to the resource (before Nurse and Doctor), theprivileges granted are same as what Nurse or Doctorwould have received (in case they were logged in). Ifa user needs to access more secure information than al-lowed at Authentication Level-I, they need to perform anadditional set of challenge/response to move to Authen-tication Level-II. At this level a user can access secureinformation that is not available to others. The greaterprivacy requirements at this level mandates strict loginand logout procedures (unlike Authentication Level-I) toprevent any loss of privacy. In actual implementation thisadditional challenge response can be easily done withminimal distractions using bidirectional smart tags likethose provided by VeriSign [27], or Ubisense [23]. Inorder to incorporate this capability in our policies, weuse the >a= V � B � B � C function to abstract the idea of userperforming the additional challenge response with thesystem.

VII. RELATED WORK

In [20], Taylor presents a look at the Smart-EmergencyDepartments of the future. The paper presents manyscenarios which describe various automations and work-flow improvements in an ED environment. Some of thepotential advances presented include: self registration,automated triage, smart medical decision making. The

paper further emphasized the need of integrating variousavailable technologies in achieving these improvements.

Smart spaces play an important role in providing therequired automation in smart-EDs. Black, et. al. [15]used health-care as an example for describing issuesrelating to building an enterprise-wide pervasive com-puting application (which involves the setup of a smartenvironment spanning an entire enterprise). Some of theissues presented include reliability, scalability, securityand privacy concerns, interaction with legacy back-endsystems and the effect of a large number of interactingdevices on the enterprise and beyond.

Further, a lot of interest in the research community hasbeen directed toward smart spaces and some of the moreprominent ones include Aware Home project where asmart home is aware of the whereabouts of its occupants[24], Microsofts Easy Living [25], Smart-Its project werethe goal is to augment every day items with addedintelligence using small-scale embedded devices thusincreasing the intelligence of the environment aroundthe user [26]. Several products are already availablein the market which provides context awareness withinan environment resulting in the deployment of smartspaces in offices, hospitals and homes, examples includeUbisense [23] and Radianse [22]. Though similar tothese in implementation (i.e. technologies used), wedescribe a different approach toward defining the ca-pabilities of smart spaces based on a set of policiesapplied to a collaborative environment. In the examplesabove, an entire environment (i.e. a house) is definedas a smart space and the focus was to develop contextbased services within them. We, however, focus on thescenario where the smart spaces are not omnipresent butare needed only in designated areas.

In the access control domain, Role Based Accesscontrol was first thoroughly studied in the seminal paperby Sandhu et al. [3]. This paper defined the basiccomponents of RBAC such as user, roles, and privileges,their interactions (constraints and hierarchy). By decou-pling the process of directly associating privileges witha user, RBAC provided an effective and easy way ofmanaging security within a system. Further, it allowedeasy implementation and enforcement of complex accesscontrol policies within the system. The concept of RBACwas generalized in [4] by incorporating subject roles,object roles and environment roles. As most systemsare dynamic in nature, RBAC was further extendedby including various context information in the accesscontrol decision making process. Some of the importantwork in CA-RBAC includes [5] which considered the

Fig. 8. All medical professionals are inside the proximity of the resource. User Doc1 is assigned the resource at random.

spatial, temporal and resource context in access controldecision making, [7] presents team based access controlmodel which is context-aware. The idea of context-sensitive access control was formally specified in [6],which attempted to perform access control based onthe context of the requested operation. McDaniel [8]suggests that context specification in CA-RBAC is imple-mentation dependent. Strembeck et. al. [11][12] providean integrated framework to engineer and enforce contextconstraints in RBAC.

Sampamane et. al. [9] present context-aware accesscontrol policies for smart spaces. They only considerspatial and subject context and define mode of accessas Individual, Shared or Collaborative depending on theaccess privileges and the number of the subjects in theactive space. The ideas from this work were furtherextended and implemented in [10], which presents aninfrastructure for context aware access control and au-thentication in smart spaces. A dynamic context awareaccess control scheme for distributed health-care applica-tions was presented in [13]. [18] presents a good surveyof access control mechanisms listed above.

In [21], Bardram et. al. explore computer security inpervasive computing with focus on user authenticationand present the concept of Proximity-Based User Au-thentication, as a highly user-friendly ideal for pervasivecomputing systems. They present a context-aware userauthentication protocol, which (1) uses a JavaCard for

identification and cryptographic calculations, (2) uses acontext-awareness system for verifying the user’s loca-tion, and (3) implements a security fall-back strategy.However, they do not concentrate on the specific require-ments of ED in their design and further do not specifythe policies which govern the automated access controldecisions in such environments.

VIII. CONCLUSIONS AND FUTURE WORK

A Proximity-Based Access Control scheme for secureresource access in a hospital emergency department is aviable technology to improve the ED work-flow, enhancedata access, and improve patient care. We have definedthe concept of proximity by identifying the contributingfactors in the design of proximity zone to a resource.Further, we introduced authentication levels to preventunauthorized access to resources based on proximityonly. We presented a detailed semi-formal specificationof the access control model in terms of policies. Thesepolicies were comprehensive in nature and controlledboth administrative and access control functions of thesystem. Finally, we designed our system to be criticalityaware, in that it has the ability to continuously monitorthe system context information and upon detecting anunusual occurrence requiring flexibility in user accesslevel, make appropriate changes in the policies to handlethe situation. Finally, we validated the model by de-veloping a prototype using the UWB-based positioning

Fig. 9. Nurse enters the proximity of the resource

system developed by Ubisense Inc. In the future workneeds to be done for: specifying a comprehensive modelfor designing proximity zones, and validating this in afunctioning ED environment with our PBAC model.

ACKNOWLEDGMENT

We greatfully acknowledge the intellectual contribu-tions of Valliappan Annamalai, Vikram Shankar of theIMPACT Lab at Arizona State University and the supportof Zach Mortensen at MediServe Information Systems.

REFERENCES

[1] L. Cook. “Staying current on defibrillator safety”. In Journal ofNursing (33)11, Nov 2003.

[2] E. Dijkstra. “Guarded Commands, non determinacy and formalderivation of programs”. In Communications of the ACM (18)8,1975.

[3] R. Sandhu, E. J. Coyne, H. L. Feinstein and C. E. Youman “RoleBased Access Control Models”. In IEEE Computer, Feb, 1996.pp38-47

[4] M. J. Moyer and M. Abamad. “Generalized Role Based AccessControl”. In Proc. of 21st Int. Conf. Distributed ComputingSystem, 2001

[5] M. J. Covington, W. Long and S. Srinivasan. “Secure Context-Aware Applications Using Environmental Roles”. In Proc. of 6thACM Symp. on Access Control Models Tech., 2001

[6] A. Kumar, N. Karnik and G. Chafle. “Context Sensitivity inRole-based Access Control”. In ACM SIGOPS Operating SystemReview 36(3), July, 2002

[7] C. K. Georgiadis, I. Mavridis, G. Pangalos and R. K. Thomas.“Flexible Team-Based Organizational Access Control using Con-texts”. In Proc. of 6th ACM Symp. on Access Control ModelsTech., 2001

[8] P. McDaniel. “On Context in Authorization Policy”. In Proc. of8th ACM Symp. on Access Control Models Tech., 2003

[9] G. Sampemane, P. Naldurg and R. H. Campbell. “Access controlfor Active Spaces”. In Proc. of ACSAC, 2002

[10] J. Al-Muhtadi, A. Ranganathan, R. H. Campbell and M. D.Mickunas. “Cerberus: A Context-Aware Security Scheme forSmart Spaces”. In Proc. IEEE Percom, 2003

[11] G. Neumann and M. Strembeck. “An approach to engineer andenforce context constraints in an RBAC environment”. In Proc.of 8th ACM Symp. on Access Control Models Tech., 2003

[12] G. Neumann and M. Strembeck. “An integrated approach to en-gineer and enforce context constraints in RBAC environments”.In ACM TISSEC 7(3), 2004, pp 392-427

[13] J. Hu and A. C. Weaver. “Dynamic, Context-aware SecurityInfrastructure for Distributed Healthcare Applications”. In Proc.1st Workshop on Pervasive Security, Privacy Trust, 2004

[14] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam and E. Cayirci.“A Survey on Sensor Networks”. In IEEE CommunicationsMagazine 40(8), 2002, pp 102-114

[15] J. P. Black, W. Segmuller, N. Cohen, B. Leiba, A. Misra, M.R. Ebling, and E. Stern. “Pervasive Computing in Health Care:Smart Spaces and Enterprise Information Systems”. In Proc.ACM MobiSys, Workshop on Context Awareness, 6 pp. June 92004

[16] K. Venkatasubramanian, G. Deng, T. Mukherjee, J. Quintero, V.Annamalai and S. K. S. Gupta “Poster - Ayushman: A WirelessSensor Network Based Health Monitoring Infrastructure andTestbed”. In Proc. IEEE International Conference on DistributedComputing in Sensor Systems (DCOSS), 2005

[17] N. Sastry, U. Shankar and D. Wagner “Secure verification ofLocation Claims”. In Proc. ACM Workshop on Wireless Security(WiSe 2003) September 19, 2003.

[18] W. Tolone, G. Ahn, T. Rai and S. Hong “Access Controlin Collaborative Systems”. In ACM Computing Surveys 37(1),March 2005, pp 29-41

[19] S. K. S. Gupta, T. Mukherjee and K. Venkatasubramanian “Crit-icality Aware Access Control Model for Pervasive Applications”.In Submission to IEEE Percom 2006

[20] T. B. Taylor “A View of the Emergency Department of theFuture.”. ACEP Section for Emergency Medical Informatics2000, Dallas, TX

[21] J. E. Bardram, R. E. Kjaer, and M. O. Pedersen “Context-Aware User Authentication - Supporting Proximity-Based Loginin Pervasive Computing”. In Proceedings of Ubicomp 2003Seattle, Washington, USA, 2003, pp 107-123

[22] Radianse Indoor positioning.http://www.radianse.com/

[23] Ubisense.http://www.ubisense.net/

[24] The Aware Home Project.http://www.cc.gatech.edu/fce/ahri/

[25] Easy Living Project.http://research.microsoft.com/easyliving/

[26] The Aware Home Project.http://www.smart-its.org/

[27] Unified Authentication Tokens.http://www.verisign.com/products-services/security-services/unified-authentication/index.html/