Paper accepted for SACMAT’02: 7th ACM SYMPOSIUM ON ACCESS CONTROL MODELS AND TECHNOLOGIES, June 3-4, 2002,

Naval Postgraduate School, Monterey, California, U.S.A.

A context-related authorization and access control method

based on RBAC: a case study from the health care domain
Marc Wilikens Simone Feriti Marcelo Masera
Joint Research Centre Alberto Sanna Joint Research Centre
Institute for the Protection and Scientific Institute Hospital San Institute for the Protection and
Security of the Citizen, TP 210, Raffaele , Via Olgettina, 60 Security of the Citizen, TP 210,
Ispra (VA), Italy 20132 Milan, Italy Ispra (VA), Italy

+39 0332 789737 +39 02 2643 2019 +39 0332 789238

Marc.Wilikens@jrc.it simone.feriti@hsr.it Marcelo.Masera@jrc.it

business processes that inspire trust for its participating

ABSTRACT
This paper describes an application of authorization and access
control based on the Role Based Access Control (RBAC) method
and integrated in a comprehensive trust infrastructure of a health
care application. The method is applied to a health care business
process that involves multiple actors accessing data and resources
needed for performing clinical and logistics tasks in the
application. The notion of trust constituency is introduced as a
concept for describing the context of authorisation. In addition,
the applied RBAC covers time constraints, hierarchies and multi-
level authorization rules for coping with the multi-actor nature and
the complexity of the application domain. The DRIVE RBAC
model clearly distinguishes between static role assignment to
users and dynamic allocation of roles at session time. The paper,
while focusing on the authorization and access control approach,
also describes how the RBAC functions have been integrated in a
trust infrastructure including smart cards.
Categories and Subject Descriptors
J.3 [Life and Medical Sciences]: Medical Information
Systems
General Terms
Security
Keywords
Role Based Access Control (RBAC), trust infrastructure, secure
health care system
1. INTRODUCTION
Authorization and access control, respectively covering the
determination and the control of rights of users to use IT assets, is
a key component in the provision of comprehensive secure
Permission to make digital or hard copies of all or part of this work
for personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial advantage
and that copies bear this notice and the full citation on the first page.
To copy otherwise, or republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee.
SACMAT’02, June 3-4, 2002, Monterrey, California, USA
Copyright 2002 ACM 1-58113-496-7/02/0006…$5.00
stakeholders. In recent literature relating to e-business [9], the
term trust is usually employed for characterising the reliance of
business actors and consumers on other actors or on IT systems.
Trust covers a variety of issues including accountability, privacy,
authenticity and safety.
The health care domain is being revolutionised by the use of
information and communication technologies to increase
efficiency of health care provision whilst increasing safety of
patients and reducing overall costs. This vision cannot however be
realised without appropriate trust in the business processes and the
information infrastructure. In particular the health domain has the
following characteristics that strongly impact the need for a
coherent but flexible approach to authorization management and
access control:
• Health care provision is a complex knowledge intensive
process. A large number of different actors from a variety of
organizational entities create value on assets by participating
in different tasks (diagnosis, therapy prescription, therapy
validation, drug administration, drug data provision, etc) in
the process.
• Privacy has always been an important requirement in health
care applications but gets a new dimension within a virtual
health care enterprise environment in which critical data can
cross established trust boundaries (e.g. crossing the physical
boundaries of a hospital ward) due to distributed
responsibilities and remote access. Privacy protection
requirements can only be satisfied if they are consistently
(but not necessarily uniformly) applied throughout the whole
business process.
• The safety dimension is of prime importance in health care.
Adverse clinical events can be reduced by IT enhanced
business process support. It is important that the HC
professional has access to context dependent information
drawn from different steps in the process to perform
consistency checks at the point of care (e.g. checking
potential drug interactions or matching patient therapy
prescription and drug related data). In addition the integrity
of critical needs to be preserved.
The aim of this paper is to describe a method for authorization and
access control to resources and data based on Role-Based Access
Control (RBAC) and to describe how such a method can be
integrated in a wider trust infrastructure in order to comply with
wider security and safety requirements. The authorization process
will be realised by means of credentials that are bound to users of
the IT resources. The smart card will serve as secure access token
including identification/authentication as well as digital signature
functions. The method is applied to the health care domain but
could as well be applicable to other domains in which multi-actor
and context dependant (remote) access to digital assets is critical.
The research that has lead to this paper is performed within the
DRIVE1 project. DRIVE aims at the development of an
information and trust infrastructure for optimising the clinical
processes and the drug supply chain processes in a health care
enterprise. Therefore, the DRIVE real case pilot covers all the
value-makers involved in the drug therapy process. This includes
the diagnosis and therapy prescription processes in the clinical
domain of a Hospital including the controlled therapy
administration to the patient, therapy validation by means of up to
date drug data, the traceability of pharmaceuticals and related
information flows from the drug supplier to the hospital logistics.
RBAC [12], as an alternative to traditional access control
methods, associates roles which each actor who might have a need
to access assets. With each role a specific set of access rights is
associated that the actor in that role may perform. The question
then remains how to define roles and their granularity. For
instance, in health care, a role could be location-based (e.g.
membership to ward) and may take the form of “Patient Clarke’s
record can be accessed by” “any health professional assigned to
the same ward as the patient”. However, grouping with strict
location constraints such as ward may become tricky when the
business process transcends physical perimeters, a situation
facilitated by distributed computing and remote access. Or role
could be based on job responsibilities in the organisation. So for
instance, “Patient Clarke’s record can be written by” “any health
professional assigned to the role of ward physician”.
The latter approach was adopted in the PCASSO project [1].
PCASSO developed a RBAC applied to a clinical domain and has
defined a number of roles including Primary care Provider,
Secondary Care Provider, etc. PCASSO also combines the role
based access control with label-based access control that isolates
different levels of sensitivity of data. Sensitivity levels could
cover e.g.: low - non identifiable data, standard - identifiable
patient data and high – genetic, mental health, HIV data.
Whereas in PCASSO, the general approach was to assign generic
clinical roles to actors independent from the clinical context in
which these actors operate, the general approach in the DRIVE
project is a business process-oriented approach. This implies
eliciting roles that are business context dependent and directly
associated with a task in the drug therapy process.
In [10] a method is proposed for access control to distributed
medical database systems using digital certificates. It proposes the
use of attribute certificates for authorisation and introduces
access-rule certificates for propagation of access control policy.
The attribute certificate approach is currently under discussion in
1
DRIVE (Drug in Virtual Enterprise) is an EU funded R&D
project conducted and supported in the frame of the EC IST
programme (IST-1999-12040). The partners are: Scientific
Institute San Raffaele, Joint Research Centre, ATOS-Origin,
Karolinska Institute, Politechnico di Milano, AstraZeneca, Glaxo-
wellcome.
standards initiatives [7]. Moreover, the management of short-lived
certificates for authorisation and access control can make their
management procedures heavy and requires appropriate certificate
management infrastructure. While referring to some of the
proposed concepts, we opted for clearly distinguishing between
static role assignment to users based on credentials and dynamic
allocation of roles determined at session time.
The following chapters describe the DRIVE authorization and
access control approach by elaborating in separate chapters on
trust constituencies, the RBAC principles adopted in DRIVE, the
operational procedure and the integration of RBAC in a
comprehensive DRIVE trust infrastructure.
2. TRUST CONSTITUENCIES
The concept of trust constituency was briefly introduced in [8] but
its use was not further elaborated. It covers individuals,
organisations and business units that have a trust stake in the
protection and in the engagement of their rights and obligations
with regard to health records. We have adapted this concept to the
DRIVE context linked to the notions of jurisdiction and trust
engagement that we define below:
Jurisdiction: Membership of the involved actors to the same
institution/organisation that defines the actors’ trust
engagement by means of organisational policies. In a
complex health care environment different organisations are
part of the value chain. Defining a jurisdiction and its
boundaries even if the latter are virtual is important for
determining responsibilities and obligations.
Trust constituency: A DRIVE trust constituency is a
logical entity within the context of a business process that
encompasses process activities and actors and is determined
by a trust engagement with regard to a certain type of asset. It
should be noted that by focusing on activities and actors
instead of physical location, one trust constituency in
principle could transcend physical locations (e.g. a ward
physician that is mobile, a remote consultant physician
providing advice on a diagnosis or a patient consulting his
records from home). In practice, a trust constituency will
often correspond with a physical premise (e.g. a hospital
ward).
Trust engagement: Prescription of a joint trust stake among
actors, defining their respective rights and obligations with
regard to certain assets handled in the course of certain
process activities.
An important privacy principle is use limitation of personal data
within predefined contexts. The trust constituency concept can be
used for determining these contexts in defining authorisation
rules. With respect to this, two key distinguishing factors
determine a trust constituency, namely: the type of asset handled
(e.g. patient-identifiable clinical data, demographic patient data,
non-identifiable clinical data, drug logistics data, drug clinical
data) and the jurisdiction. A hospital (corresponding to one
jurisdiction) can have different trust constituencies based on the
legitimate need for its users to access patient identifiable clinical
data (e.g. identifiable clinical data should be handled only in the
hospital clinical activities). Therefore, the concept of trust
constituency imposes constraints on how actors can access the
different assets. It also puts constraints on the transfer of assets
from one constituency to the other. For instance if there is a
legitimate need for transfering to third parties (e.g. insurance - Mutual exclusion: In the organization of the DRIVE RBAC
company) identifiable clinical data for the execution of the approach determines both static and dynamic exclusion rules.
contract, then this becomes another trust constituency because it is Static exclusion means that some actors cannot be authorised
a different jurisdiction. The transfer of data then needs to be done for different roles: e.g. nurse and ward physician; Dynamic
under controlled conditions by a trusted entity that is accountable exclusion means that an actor cannot act simultaneously in
(e.g keeping disclosure registers). both roles: e.g. ward physician and on-call physician.
Figure 1 gives a schematic overview of four trust constituencies - Time constraints: Determines role activation and permission
assignment based on time.
Identifiable Context control impacts the functional architecture of the RBAC
clinical data
Clinician system in two ways. First, it allows to distinguish between
Patient drug activated roles and predefined roles for a particular user. The set
prescription of predefined roles of a user is determined at registration time and
Clinical profiles
based on user’s credentials. The working context (constituency,
time) of a particular user combined with dynamic exclusion rules
non- determine which subset of predefined roles allocated to that user
Drug clinical identifiable can be activated at session time (e.g. on-call physician can only be
data clinical data activated during night time). Secondly, knowledge of the user
Clinical Support -
context also contributes to refine the permission assignment to
Pharmacist Pharmacy roles. Usually, permissions are statically assigned to roles (e.g.
read and write therapy data is assigned to ward physician). It
allows to dynamically adapt permission assignment for a
particular role dependent on specific user context constraints, for
Patient Drug logistics
Pharmacist instance based on the location of the user (e.g. no write access to
demographic data
data
therapy data if a ward physician is outside his default trust
Administrative & logistics
constituency, i.e. ward).
H admin clerk logistics operator
As a general principle, access rights for assets are reduced when
actors are not in the same trust constituency in which the asset
originates. Furthermore, the context parameters implement the
need-to-know principle, for example the need to know of patient
Drug data identities for users outside the ward should be limited.
Drug Supplier Suppliers

3.2 Dynamic properties

Figure 1: Trust Constituencies in DRIVE
within the DRIVE system. For instance the clinical trust
constituency, concerns activities performed on patient related
clinical objects (the patient himself, biological samples) and
acting on patient-identifiable clinical data. The trust constituency
could be further fine grained for instance by covering a specific
ward. The clinical support trust constituency is in the DRIVE
pilot limited to pharmacy clinical support activities. It provides up
to date drug related data to wards and accesses clinical data for
validating drug prescriptions and keeps statistics on therapies
effectiveness. The implication is that a pharmacist can belong to
two trust constituencies because of his/her clinical support and
logistics functions.
3. RBAC PRINCIPLES
The DRIVE authorisation and access control approach is based on
establihed RBAC principles [12] and furher work. How these
principles are applied or adapted is explained in this chapter.
3.1 Context control
Context control is highly important for authorisation and access
control to resources in distributed health care processes in which
multiple actors add value to critical assets. In [10], context control
is primarily based on location (site, domain, etc). We propose to
include the following parameters:
- Trust constituency: Determines where an actor normally
performs his functions, his rights and duties.
We need to extend the RBAC model with dynamic properties
applied to the role activation function. This allows the system to
be most flexible and most suitable for the Health Care
environment. For instance there is a need to cope with specific
access privileges of on-call physicians on night duty.
For the dynamic extension of RBAC in DRIVE we introduce a set
of expressions that allow specification of these properties. The
basic expression is the event expression and the conditions that
produce these events. The conditions are based on a set of context
events, including time [2], trust constituency and an additional
specific time related condition, namely formality context for
specifying urgency.
Event expressions
1. Event expressions (Ei ) have the form activate (U,R) or
deactivate (U,R), where U ∈ USERS and R ∈ ROLES.
2. Prioritized event expressions have the form p:E, where p ∈
PRIOS and E is an event expressions.
3. We say that two event expressions activate (U,R) and
deactivate (U’,R’) are conflicting if U=U’ and R=R’; in
symbols, we write:
conf(activate (U,R)) ≡ deactivate (U,R)
conf(deactivate (U,R)) ≡ activate (U,R)
Role status
Role status expressions (Ci ) have the form active (U,R) or
┐active (U,R), where U ∈ USERS and R ∈ ROLES.
Context events
Context events (CE) are of the form (I, P, W, F,p:E), where:
I is a time interval of the form [begin, end]. If the expression
is always true the form is [-∞,∞]
P is a periodic expression (time context)
W is a place expression (trust constituency or ward context)
F is a formality expression (routine or emergency)
p:E is a prioritized event expression
3.3 Hierarchies
The concept of hierarchy is important in multi-actor RBAC and it
reflects the structure of the organization and the respective
responsibilities of the roles. Hierarchies of user roles will be used
for permission inheritance [5]. Refer to the RBAC model
explained in chapter 4 for examples of role hierarchies.
3.4 Multi-level Authorisation rules
A typical authorisation rule in DRIVE would be composed of:
A user role within a user context has authority to access a
function and has authority to access an operation on assets.
For instance a ward physician within the same ward of the
patient has authority to access the therapy prescription
function and has authority to read the patient record and write
the therapy.
This rule differs from the 3DAM (3-dimension access matrix) rule
described in [10] in that we have introduced an additional control
level, namely at the functional level and this for two reasons.
Firstly, in DRIVE the business process approach calls for a large
set of functions within an application range covering clinical,
composed of three broad groups: Patient demographic data,
hospital stay data and patient clinical data. This means the
permission or not for a user role within a certain context and
within a given application to execute operations on a specific
group of data items in the asset (e.g. read patient clinical data
or write therapy data in the patient record).
4. DRIVE RBAC MODEL
In this chapter, we describe the DRIVE RBAC model according to
the DRIVE application case and taking into account the RBAC
(PA)
Permission
(UA) User
Assignment
Assignment Functions
Ops_Fnc
Users Roles
Ops_Asset Assets
User/
session Session/roles
Sessions PRMS
Figure 2: RBAC reference model
principles from the previous chapter. Guidance is given by a
proposed standard for Role-based access control [6] that describes
how to specify a Core RBAC reference model. It is applied to the
DRIVE requirements and adapted to cope with multi-level
authorization rules, including access control to application
functions as well as assets. The resulting RBAC model consists of
specifying the following entities and associations (figure 2).
The set of users (USERS) is understood as the user categories
that need accessing different resources in the DRIVE application
servers, including clinical and logistics. For example, in Trust
Constituency 1 (TC1 – Clinical), the clinical user category
includes: Head physician, Ward physician, On-call physician,
Clinical

logistics and collaborative logistics applications. These functions

are accessible from a common DRIVE portal. Therefore, we want
access control at application level. Second, this approach allows
for a gradual implementation of the RBAC in DRIVE starting
from access control to functions and subsequently addressing data
access control. Nurse On-call Phy sician Ward Phy sician Serv ice Phy sician

The levels of granularity of access control then comprise:

• Functions: At the highest level, access control to applications
and functions (e.g. the therapy prescription function). This
means the permission or not for a user role within a certain
context to access a function. Head Nurse Head Phy sician

• Digital asset: Second level, access control to operations on
whole assets. Operations would typically include: create, read,
write, modify, delete. This means the permission or not for a
user role within a certain context and within a given function
to execute operations on whole assets (e.g. read the whole
patient record).
• Data items: Third level, access control to specific groups of
attributes in an asset. The patient record for instance is
Figure 3: clinical user categories
Service physician, Head nurse, nurse (figure 3). In DRIVE, a
single user category can belong to different trust constituencies.
For instance, in the hospital, a pharmacist belongs to TC2 –
Clinical Support as well as to TC3 – Administrative & Logistics.
The definition of roles (ROLES) in DRIVE is explicitly related
with the business process tasks that are performed in the clinical
and logistics trust constituencies. For instance, the roles that
perform clinical activities in the clinical Trust Constituency
include: Anamnesis Maker, Diagnosis Maker, Therapy Prescriber,
Consultant, Therapy Preparator, Therapy Administrator and Data
Collector of patient health state.
The roles in the Trust Constituency 2 – clinical support include:
Therapy Validator, Hospital Formulary & Ward Profile (HP&WP)
Definition, Drug Utilization Review (DUR) Analyser.
based on the specific profile of the user. In principle more than
one role can be assigned. Static exclusion rules and hierarchies
will be taken into account for defining user assignment. As an
example, two role hierarchies are shown in the figures 4 and 5
covering respectively the clinical staff assignment and the clinical
support staff. It is noted that therapy validator, DUR analyzer and
HF-WP definition are clinical support roles performed by a
pharmacists whereas request validator and drug warehouse
manager are two logistics roles performed by pharmacists. The

clinical
manager

head head pharmacy

physician nurse director

anamnesis diagnosis prescriber prescription consultant therapy therapy therapy DUR HF-WP request warehouse
maker maker validator preparator administrator validator analyser definer validator manager

on-call ward service nurse pharmacist

physician physician physician

clinical clinical logistics/admin

staff support staff staff

Figure 4: Role hierarchy for clinical staff Figure 5: Role hierarchy for Pharmacist
The set of functions (FUNCTIONS) contains about 50 different latter two roles can only be activated from the logistics trust
functions (e.g. therapy prescription, etc) that are subdivided into constituency.
the four application servers: clinical, logistics, collaborative
logistics and Hospital Information System (HIS). They represent By convention, more authorative roles are towards the top of the
the main Use Case models for the DRIVE application. diagrammes. In figure 4, the head physician is senior to ward
physician and inherits all permissions from ward physician.
The CC standard [3] defines an asset as information or resources
to be protected by the countermeasures of a target of evaluation Session/Role association A user session is associated with a
(TOE). In DRIVE, within the RBAC context the set of assets subset of the roles authorized for the user and this subset, often
(ASSETS) focuses on information assets. Access control to referred to as the active role set (ARS), is determined by dynamic
computing resources is covered by controlling the access to exclusion rules and temporal constraints. The dynamic conditions
functions. The categories of information assets include patient are implemented by an activation/deactivation function. In the
data, drug data and health care professional data. The patient data following table 1 we show an example of an
comprise three groups of data items: patient demographic data, activation/deactivation function for the on-call physician role.
hospital stay data and clinical data. The clinical data are patient Table 1. On-Call Physician session/role association (the trust
health data collected during the hospitalisation episode. The HC constituency context parameter is the ward number)
professional data include credentials and identity information.
Time Ward Formality Priority Event
The set of operations on functions (OPS_FNC) specifies the Context Context
legitimate operations on the set of functions. The basic operations Night- Inwards Routine/ H Activate (On-Call Physican,
on functions are only binary: access to a function or no-access to a time Emergency Prescriber)
function. Day- Inwards Routine/ H Deactivate (On-Call
The set of operations on assets (OPS_ASSET) specifies the set time Emergency Physican,Prescriber)
of legitimate operations that can be performed on whole assets or Night- Inward Routine/ H Activate (On-Call Physican,
groups of attributes contained in them. In Drive, we identify: time Emergency Diagnosis Maker)
create (constructs an object and initializes its data); read (reads an Day- Out- Routine/ H Deactivate (On-Call
object or a subset of attributes of them); write (inserts the data in time Ward Emergency Physican, Diagnosis Maker)
an object or in a subset of attributes of the object in append
mode); modify (writes an object or a subset of attributes of it in
update mode); copy (copies the data of an object in a different Finally as last step in the procedure, the permission assignments
object); delete (delete an object and the data related with them). define access policies for different roles.

The User assignment (UA) is a key association in an RBAC Permission assignment 1 covers the Role/OPS_FNC association.
policy definition. It assigns roles to each individual user category For each role, the access rights on applications and functions are
defined. For example covering applications: Clinical staff →
clinical application server; For example covering functions: Ward
Physician → all clinical functions; service physician →
Diagnosis.
Permission assignment 2 covers Role/OPS_ASSET association.
For each role, permissions on assets are defined. The RBAC
model should allow for roles having overlapping permissions. For
example, read permission rights may be allowed for all clinical
staff (physicians and nurses) belonging to the trust constituency
(ward) where the patient record originates, while writing the
therapy on the patient record may be specific for the “therapy
prescriber” role. The framework should also leave the possibility
for more restricted ACL’s, in particular lists containing a single
named health professional (e.g. in case of very sensitive health
data or in case of celebrity patients).
For example: Prescriber, Consultant → Read (Patient
Demographic Data, Hospital Stay Data, Patient Clinical Data,
Therapy Sheet); Prescriber, Consultant → Read (Drug product
data); Prescriber→ Create/Write/Modify (Therapy Sheet);
Prescriber → Create/Write/Modify (Therapy Data); Consultant →
Write(Therapy.Therapy Advice)
5. FUNCTIONAL ARCHITECTURE
Taking into account the RBAC principles and model explained in
the previous chapters, the functional architecture for authorisation
and access control in DRIVE consists of the following instances
(figure 6).
The first instance, user assignment, is executed off-line. Each
potential DRIVE user of clinical or logistics systems registers
with the DRIVE Certificate Authority (CA) and obtains an
X509 identity certificate. Authorisation credentials (Roles) are
assigned based on the identity of the user and additional
identity properties (profession, specialty, etc..). In addition,
the default trust constituency of the user is specified (e.g. ward
number 5 or pharmacy or logistics, etc). This assignment is
performed on behalf of a Credential Issuer (e.g. clinical
director of a Hospital for clinical roles or personnel
department for other roles). By issuing a credential certificate
next to the identity certificate, the Credential Issuer certifies
that the user owns a specific property that determines his/her
role(s) in the business process. Static exclusion rules are
applied here for roles assignment. Credential systems are not
new in IT security. In [3], a credential system is described but
applied to identity management and anonymity services on the
Internet. In DRIVE, its prime use is RBAC applied to a multi-
user health care business environment.
The subsequent instances of the architecture apply online; i.e.
during a session of a user. During user/session association,
before users can start a new DRIVE session with one of the
DRIVE applications, they are identified and authenticated.
Strong authentication supported by smart card and identity
certificates are used.
The subsequent instance covers Session/role association. After
successful authentication, the user context is determined
(time, place from which a session is started). The user
activates one or more of the roles previously assigned to him
in order to accomplish a certain task in the business process.
As a general approach and for efficiency reasons, we allow
users in DRIVE to choose a common role with less authority
(towards bottom in the role hierarchy) with the possibility to
specialise the role subsequently if needed. Thus a ward
physician, would typically log a session as ward physician for
performing all the normal ward tasks. Dynamic context
control applies and some form of automated control is
possible here. Indeed, the dynamic exclusion rules explained
in the previous chapter put constraints on the choice of roles
in a certain context. For instance, time context for an on-call
physician. The set of activated roles and the user context form
a session/role association.
User assignment: authorization credentials (roles)
are assigned to user
User/session association: Identification and
authentication of user
Session/role association:
User activates roles and the user context is
determined
Access a function in a particular session
Access control to the application/function
Access control on the operations on assets
Log out of the session
Figure 6: DRIVE RBAC functional architecture
After activation of a subset of roles and determination of the
context, the actual access control decision-making process
takes place following a 3-level process. The decision making
process is specified as a set of permission assignments on
applications, functions and assets as outlined in the RBAC
model. The user requests access to one of the functions in the
DRIVE application servers. For instance the therapy
prescription function in the clinical application system. Also
here dynamic context control applies based on context
parameters for refining the permission assignments.
The first level access control mechanism is activated for
determining if the session/role association is authorized or not
to access the function.
Then second level checking determines if operations on whole
assets can be performed.
The third-level access control mechanism checks permissions
on the groups of data items. Permitted access requests are
performed by the database server and results returned.
The session is logged off and the cycle starts again at step 2:
user/session association.
It is noted that the functional architecture explained above is
privacy enhancing because it allows for selective access to critical
personal assets in the complex multi-user environment of DRIVE.
Strong authentication of actors is necessary for accountability
reasons. Privacy concerns primarily regard patient data protection.
In some instances of the business process, there are also privacy
needs of the actors themselves. For instance, clinicians’ identity
should not be disclosed when patient records are legitimately
accessed from outside the clinical trust constituency. In this case,
RBAC needs to be combined with anonymity technologies. In an
e-commerce environment on the other hand, privacy can be
enhanced notwithstanding the need for strong authentication.
Indeed, the approach allows for a clear separation between
user/session association on one side and session/role association
on the other. The former can be performed by means of strong
authentication of the user to a trusted third party. For the latter the
trusted third party performs the session/role association on behalf
of the service provider without disclosing the real identity of the
user to the service provider.
• Authenticity assurance: Covers the authenticity of the
(critical) data content by creating digital signature envelopes
around changed parts of critical assets.
• Identity protection: Covers anonymising technology applied
to patient records for protecting patient and clinician’s
privacy after patient dismissal from ward.
• Trust support functions: A set of functions that support the
implementation of the trust functions specified above. They
include for instance identification/authentication,
key/certificate management, digital signature,
encryption/decryption.
• IT infrastructure protection: Covers secured communication
channels that assure integrity and confidentiality between
systems in the distributed DRIVE system architecture.
The part of the DRIVE trust infrastructure that supports the
authorsisation and access control functions covers the following
instances (figure 7):

6. TRUST INFRASTRUCTURE WITH
RBAC FUNCTIONALITY
The RBAC authorization and access control approach is
integrated in the DRIVE trust infrastructure. The DRIVE trust
infrastructure covers a wider set of trust functions needed to
support the safety and security requirements, and is composed of:
• Real-time validation and verification: Covers data correlation
and integrity checks on physical and digital assets.
• Authorisation and access control: Covers the role-based
access control policy and mechanisms.
• DRIVE CA: Certificate Authority. Issues identity certificates
to users and to the Credential Issuer. In addition, manages the
life-cycle of keys and certificates. All published and certified
keys can be fetched from its directory function.
• The Credential Issuer: Assigns roles to the different users of
the DRIVE applications. By issuing a role, the credential
issuer certifies that the user owns a specific characteristic.
Therefore, the data structure containing the roles of a
particular user is digitally signed by credential issues. In
addition it publishes its public key that can be used to verify
these roles.

Certificates
generation Directory

DRIVE CA LDAP server

Roles
Assignment Certificate services Crypto
services
Credential issuer

API
DRIVE
Authentication
Server signature/en (de)cryption

Smart
Card User R
Work DRIVE
B
station Application
session login A servers
DRIVE C
actor

Figure 7: RBAC in the DRIVE trust infrastructure

• Smart Card: Hardware/software token to store in a secure
way a number of data structures needed for digital signature,
authentication, authorisation and access control. These
include: user’s private key, certificate and PIN number.
• Authentication Server: Authenticates user, fetches roles
assigned to the user from the directory and passes them on to
the application server.
A key requirement is to conceive the RBAC system as
middleware that can be easily integrated with the different
applications covering clinical and logistics and running on
different computing platforms. In addition, it must interoperate
with the appropriate trust infrastructure components. Existing
software security packages, predominantly based on proprietary
solutions, are still lacking maturity with this respect. Java-based
API’s with crypto libraries for accessing security functions, key
exchange and certificate verification mechanisms are emerging on
the market. Similarly, an open RBAC API would in turn promote
interoperability and portability.
7. CONCLUSIONS AND OUTLOOK
This paper has described the requirements for authorization and
access control of an integrated health care business process. We
outlined how state-of-the-art RBAC models can be applied and
adapted for satisfying these requirements and how an RBAC can
be integrated in a wider trust infrastructure including the use of
Smart Cards.
The emerging health care domain is characterised by complex
business processes with multiple actors interacting on critical
assets. Safety and privacy are key requirements. There is a need
for an authorization and access control approach that is coherent
but not uniform across different business units and organizations.
At the same time it must be flexible and easy to manage.
RBAC as an emerging technology provides potentially interesting
solutions for these needs. The flexibility should however not be
hampered by specific implementation constraints imposed by
proprietary solutions. Therefore, RBAC should be designed as a
platform independent middleware solution that is applicable to
distributed heterogeneous application environments. The role of
standards will be important with this respect, in particular for
supporting RBAC solutions combined with authentication
infrastructures and PKI’s. Apart from the standards initiatives
referred to in this paper, another important initiative is XACML,
an XML based standard for exchanging authorisation information
over the Internet, being defined by the OASIS [11].
An open question to be further investigated also in the DRIVE
pilot is the function and level of autonomy given to smart cards.
For instance, evaluating the trade-off between storing
authorisation information (roles) on the smart card and a more
centralised management of authorisation credentials. For this
evaluation, apart from performance criteria, we also need to
consider risk criteria related to fraudulent use of roles (identity
theft) and privacy.
8. ACKNOWLEDGEMENTS
We would like to thank the whole DRIVE project team for their
contributions to the development of the DRIVE trust
infrastructure, in particular Stefania Petrini, Sandro Buso, Gunnar
Klein and Francesco Faenzi.
9. REFERENCES
[1] Baker, Dixie. “PCASSO: A model for Safe Use of the
Internet in healthcare”. Journal of American Health
Information Management Association (AHIMA), March
2000.
[2] Bertino E., Bonatti P., Ferrari E. “TRBAC: A Temporal
Role-based Access Control Model”. ACM Transactions on
Information and System Security, 4(3), 2001
[3] Clauss S., Kohntopp M. “Identity management and its
support of multilateral security”. In Computer Networks 37
(2001) 205-219, Elsevier Science B.V.
[4] Common Criteria for Information Technology Security
Evaluation. CC version 2.1, August 1999. (aligned with ISO
15408:1999). Common Criteria project Sponsoring
Organisations.
[5] Ferraiolo, Cugini, Kuhn “Role Based Access Control:
Features and Motivations". Computer Security Applications
Conference, 1995.
[6] Ferraiolo D. F., Sandhu R., Gavrila S., Kuhn D. R.,
Chandramouli R. : “ A proposed standard for Role-Based
Access Control” December 18, 2000.
[7] Health Informatics: Public Key Infrastructure:
Part 1: Framework and overview. ISO/TC 215 N188, Draft
Technical Specification ISO/DTS 17090-1.
[8] ISO TC 215/WG2: Healthcare Informatics – Trusted End-to-
End Information flows. Technical report, 1 November 2000.
[9] Jones S., Wilikens M., Morris P., Masera M. “Trust
requirements in e-Business”, Communications of the ACM
(Association for Computing), Vol. 43, No 12, December
2000.
[10] Mavridis I., Georgiadis C., Pangalis G., Khair M.: “Access
Control based on Atrribute Certificates for Medical Intranet
Applications”. Journal of Medical Internet Research (JMIR)
2001:3(1):e9.
[11] OASIS: Organization for the Advancement of Structured
Information Standards. eXtensible Access Control Markup
Language (XACML). See http://www.oasis-
open.org/committees/xacml/
[12] Sandhu R, Coyne E.J., Feinstein H.L., Youman C.E.. Role-
based access control models. IEEE Computer, 29 (2),
February 1996.