An approach to access control in electronic health record.

Abstract

OASIS is a non-for-profit consortium that drives the development convergence and adoption of open standards for the global information society. It involves more than 600 organizations and individuals as well as IT leaders Sun, Microsoft, IBM and Oracle. One of its standards is XACML which appeared a few years ago and now there are about 150,000 hits on Google. XACML (eXtensible Access Control Markup Language) is not technology related. Sun published in 2004 open source Sun XACML which is in compliance with XACML 1.0. specification and now works to make it comply with XACML 2.0. The heart of XACML are attributes values of defined type and name that is to be attached to a subject, a resource, an action and an environment in which a subject request action on resource. In that way XACML is to replace Role Based Access Control which dominated for years. The paper examines performances in CEN 13 606 and ISO 22 600 based healthcare system which uses XACML for access control.

Full text

Page 1

ORIGINAL PAPER
An Approach to Access Control in Electronic Health Record
Snezana Sucurovic & Dejan Simic
Received: 9 December 2008 /Accepted: 17 March 2009 /Published online: 8 April 2009
# Springer Science + Business Media, LLC 2009
Abstract OASIS is a non-for-profit consortium that drives
the development convergence and adoption of open stand-
ards for the global information society. It involves more
than 600 organizations and individuals as well as IT leaders
Sun, Microsoft, IBM and Oracle. One of its standards is
XACML which appeared a few years ago and now there are
about 150,000 hits on Google. XACML (eXtensible Access
Control Markup Language) is not technology related. Sun
published in 2004 open source Sun XACML which is in
compliance with XACML 1.0. specification and now works
to make it comply with XACML 2.0. The heart of XACML
are attributes values of defined type and name that is to be
attached to a subject, a resource, an action and an
environment in which a subject request action on resource.
In that way XACML is to replace Role Based Access
Control which dominated for years. The paper examines
performances in CEN 13 606 and ISO 22 600 based
healthcare system which uses XACML for access control.
Keywords Securityandprivacy.Accesscontrol.
ElectronicHealthRecord
Related work on using XACML
At the RSA 2008 Conference, members of the OASIS open
standards consortium, in cooperation with the Health
Information Technologies Standards Panel (HITSP), dem-
onstrated interoperability of the Extensible Access Control
Markup Language (XACML) version 2.0. Simulating a real
world scenario provided by the US Department of Veterans
Affairs, the demo showed how XACML ensures successful
authorization decision requests and the exchange of
authorization policies. The XACML Interop at the RSA
2008 conference utilizes requirements from Health Level
Seven (HL7), ASTM International, and the American
National Standards Institute (ANSI) [1].
For security reasons, enterprises are frequently unwilling to
publicize the security mechanisms they use internally, and
many deployments of XACML fall into this category.
However, a large and growing number of businesses, institu-
tions anduniversity/researchgroups are nowusingXACMLin
their security systems. An example is children’s hospital in
Boston. The world’s first personally controlled health record
system, called Personal Internetworked Notary and Guardian
(PING), enables a patient to own a complete, secure copy of
his/ her record, integrating health information across sites of
care and over time. PING utilizes the XACML Library to
implement the necessary authorization functionality [2].
Another example is Australian’s project NEHTA (Na-
tional E-Health Transition Authority) which recommends
XACML as a standard method of defining access policies
for e-health services. [3]
Related work on access control standards
Commite European de Normalisation (CEN) standard ENV
13606 [4]
In 2008 ISO gave ISO 13 606 on Electronic Healthcare
Record Architecture. This standard is a revised Commite
J Med Syst (2010) 34:659–666
DOI 10.1007/s10916-009-9279-4
S. Sucurovic (*)
Institute Mihajlo Pupin,
Belgrade, Serbia
e-mail: snezana@lab200.imp.bg.ac.yu
D. Simic
Faculty of Organisational Sciences,
Belgrade, Serbia

Page 2

European de Normalisation standard CEN ENV 13 606.
This standard is the basis for access control in European
standards and developed systems. The main item in the
CEN healthcare information system architecture (CEN,
2002) standard is an architectural component. The archi-
tectural components are organized in a hierarchical struc-
ture. Each architectural component has a reference to access
control list for that component defined as distribution rules.
A distribution rule comprises classes Who, Where, When,
Why and How which define who, where, when, why and
how is allowed to access the component (Table 1). To access
the system a user presents his attributes that correspond to
attributes of class Who, When, Where, Why and How.
Classes Who, When, Where, Why and How are processed
with operator AND. There can be one or more DRs
attached to AC and they are processed with operator OR.
ISO 22 600 standard [5]
ISO/TS 22600-1:2006 is intended to support the needs of
healthcare information sharing across unaffiliated providers
of healthcare, healthcare organizations, health insurance
companies, their patients, staff members and trading
partners. It is also intended to support inquiries from both
individuals and application systems. ISO/TS 22600-1:2006
supports collaboration between several authorization man-
agers that may operate over organizational and policy
borders.
EXtensible access control markup language (XACML)
XACML is an OASIS [6] standard that describes both a
policy language and an access control decision request/
response language (both written in XML). The typical setup
is that someone wants to take some action on a resource, so
the elements of request are user’s attributes, action and
resource to be accessed. The request/response language lets
you form a query to ask whether or not a given action
should be allowed and interpret the result.
The currency that XACML deals in is attributes.
Attributes are named values of known types. Specifically,
attributes are characteristics of the subject, resource, action
or environment in which the access request is made. A
user’s name, their security clearance, the file they want to
access, and the time of day are all attribute values. When a
request is sent to a policy decision point (PDP) (which
makes a decision), that request is formed almost exclusively
of attributes, and they will be compared to attribute values
in a policy to make the access decision.
SunXACML
This paper presents work with Sun’s version of XACML
[7]. Sun’s XACML has supported only XACML 1.0 and
not XACML 2.0 yet. XACML 2.0 supports Security
Access Control Markup Language (SAML) protocol which
is enveloping protocol and provides a standardized protocol
for the encryption and decryption of attributes and policies
on the net.
Since Sun XACML is in developing phase (toward
version XACML 2.0) in order to work with it, it is
necessary to download form Code Version System (CVS)
( from sourceforge.net) the last version of java classes and
then compile them using given build.xml file. Finally it is
necessary to build a jar archive using Apache’s Ant tool. In
that way, we can obtain the most stable version of Sun’s
XACML, since code for version 2.0 is added in this phase
of development.
Writing access control policies using XACML
A policy is a policy set which comprises one or more
policies, where a policy comprises one or more rules. There
are also combining algorithms for policies and rules. For
example if the combining algorithm is “ordered-permit-
overrides” the first rules that permit access have advantage.
In that case the last rule is
<Rule RuleId=”FinaleRule” Effect=”Deny”/>
that means that if there is not a previously written permit
rule access is forbidden.
There is also another case when we write as the last rule
<Rule RuleId=”FinaleRule” Effect=”Permit”/>
Table 1 Distribution rules attributes
ClassAttributeType
WhoProfession
Specialisation
Engaged in care
Healthcare agent
Episode of care
Episode reference
Country
Legal requirement
Healthcare process code
Healthcare process text
Sensitivity class
Purpose of use
Healthcare party role
Access method
Consent required
Signed
Encrypted
Operating system security rating
Hardware security rating
Software security rating
String
String
Boolean
Class
String
String
String
Boolean
String
String
String
Class
Class
String
Class
Boolean
Boolean
String
String
String
When
Where
Why
How
660 J Med Syst (2010) 34:659–666

Page 3

Besides Rules, a Policy comprises a Target which is
necessary to find a correspondent policy to the given request.
A target comprises <Subject> attribute, <Re-source>
attribute and <Action> Attributes, where subject and
resource are mandatory and action can be <AnyAc-tion/>.
Subject attribute has to be of datatype RFC 822 (for
example users.example.com), and resource attribute has to
be of type <anyURI>(for example http://server.example.
com).
There can be several Subject and Resource attributes in
Request (besides ones that are part of Target in Policy). An
example of XML segment which represents Target Re-
source attribute has been given as follows:
<Resource>
<Resource Match MatchId=anyURI-equal>
<AttributeValue Data-Type=anyURI>http://server.
example.com<AttributeValue/>
<ResourceAttributeDesignatorDataType=anyURIAttri-
buteID=resource_id>
<ResourceMatch>
<Resource>
It means that a matching evaluation operator is any-URI-
equal, that attribute is of type anyURI and that its value is
http://server.example.com. Also, name of the attribute is
resource_id, that is how it is compared with attributes from
Request.
In a Policy a Target is followed by one or several Rules.
While a target is a simplified condition for access decision,
the heart of most Rules is a Condition which is mostly a
boolean or set function. If the Condition evalu-ates to true,
then the Rule's effect (a value of Permit or Deny that is
associated with successful evaluation of the Rule) is
returned. A Condition can be quite complex, built from an
arbitrary nesting of non-boolean functions and attributes.
The following XML segment presents a complex Condition:
<Condition FunctionId=string-at-least-one-member-of>
<SubjectAttributeDesignator
DataType=string AttributeId=group />
<Apply FunctionId=string-bag>
<AttributeValueDataType=string>GP
<AttributeValue/>
<AttributeValue DataType=string>SCP
<AttributeValue/>
</Apply>
</Condition>
It means that this is an attribute of subject with name
group and type string. Set function string-at-least-one-
member-of means «at least one member of set whose
elements are of type string». This segment means that
attribute of subject with name group has to have at least one
of given values (GP, SCP) in oder to access decision
evaluates to permit (Fig. 1).
Performance examination
Related work on hierarchy access control policies
ARTEMIS is an EU funded project that is developing a
semantic web service based on P2P interoperatibility
infrastructure for healthcare information systems [8]. An
ARTEMIS pilot application is being clinically deployed by
class joms1
SR_Policy
Structural_Role
Principal
SessionProcess_Policy
Functional_Role
FR_Policy
Target_Component
Target_Policy
Permission_AssignmentUser_Assignment
User_Assignment
Role_Hierarchy
Session_Role
User_Session
Fig. 1 ISO 22 600 access control policies
J Med Syst (2010) 34:659–666 661

Page 4

healthcare providers located in two European countries to
demonstrate the interoperatibility of healthcare information
systems across organizational and country boundaries. The
pilot application includes healthcare providers South East
Belfast Healthcare Trust (SEBT) in Belfast, Northern
Ireland and Hacettepe Hospital in Ankara, Turkey. In
ARTEMIS, healthcare providers define privacy policies
that state which healthcare professionals are able to access
specific medical data. The initial approach is to allow a
healthcare provider to develop role ontology that defines
the clinical occupations for healthcare professionals within
their organization. These roles are then attached to concepts
in the clinical concept ontology. As medical data is
described using the clinical concepts, authorization is
enforced based on the role of the healthcare professional
and the clinical concept being accessed. The clinical
concept ontology has been derived from the Unified
Medical Language System (UMLS) semantic network [9]
and Metathesaurus [10] to provide a rich set of terminology
for describing medical data semantics. The Semantic
Network consists of a set of broad subject categories, or
semantic types, that provide a consistent categorization of
all concepts represented in the UMLS Metathesaurus, and a
set of useful and important relationships, or semantic
relations, that exist between semantic types. The Metathe-
saurus is a very large, multipurpose, and multilingual
vocabulary database that contains information about bio-
medical and health related concepts, their various names,
and the relationships among them. The Metathesaurus is
organized by concept or meaning. In essence, it links
alternative names and views of the same concept and
identifies useful relationships between different concepts.
There are efforts to implement mechanisms for parsing free
text into UMLS concepts.
Event
Activity
Behavior
Social Behavior
Individual Behavior
Daily or Recreational Activity
Occupational Activity
Smart Card Clinical Server I
Clinical Server II
Clinical Server N
Central
Server
LDAP
Server
LDAP
Servers
Fig. 3 MEDIS System architecture
Healthcare Organisation ‘A’
(Service Requestor)
Organisation ‘B’
(Service Provider)
Security
Policy
Artemis Mediator
Superpeer
Security Brokering Module
Artemis Mediator
Superpeer
Security Brokering Module
Security
Policy
Security
Ontolo-
Security
Expert
Security
Ontology
Mapping
Security
Ontolo-
Security
Ontology
Mapping
Fig. 2 ARTEMIS security
brokering
662 J Med Syst (2010) 34:659–666

Page 5

Healthcare Activity
Laboratory Procedure
Diagnostic Procedure
Therapeutic or Preventive Procedure
Research Activity
Molecular Biology Research Technique
Governmental or Regulatory Activity
Educational Activity
Machine Activity
Example of current UMLS semantic relations [10]:
functionally_related_to
performs
carries_out
exhibits
practices
occurs_in
process_of
uses
manifestation_of
indicates
result_of
The ARTEMIS mediator can broker between privacy
policies using ontology mappings linking organisational
role ontologies with clinical concept ontologies. When a
web service is invoked the mediator translates the role
of the healthcare professional in the requesting organisa-
tion to the equivalent role in the providing organisation
(Fig. 2).
MEDIS (Medical Information System) prototype
approach
MEDIS [11] prototype has been developed as EHR when
integration from the very beginning is needed. It has been
implemented as a federated system.
As MEDIS is a multidomain system XACML should be
applied for access control. There are master access control
policies on the central server and local policies on clinical
servers. Architectural Components could be seen as
resources or target and there are access control policies
attached to them according to ISO 22 600. There are also
subject attributes enveloped in attribute certificates [12]. We
did a step further: we supposed that attributes in policies are
hierarchically organized (as in ARTEMIS) and measured
performances (Figs. 3 and 4).
Performance examination
Figure 5 presents a forest attribute hierarchy, while Fig. 6
presents a tree attribute hierarchy. Results in Tables 2, 3, 4
have been obtained on 512 M RAM-a and 800 MHz CPU.
Node 1 presents an attribute which is possessed by a
subject, while node 2 represents an attribute which is
attached to a resource. Table 2 contains access control time
results with a forest like access control policy while Table 3
contains access control time results with a tree like access
control policy.
•Phys0
•Phys11
•Phys12
•Phys21

•Phys31
•Phys22 •Phys23

•Phys32 •Phys33
Fig. 6 Tree attribute hierarchy
•Phys0
•Phys11
•Phys12
•Phys21
•Phys22 •Phys23
•Phys31 Phys32 •Phys33
Fig. 5 Forest attribute hierarchy
Attribute Certificate’s
Attributes
attributes)
(Subject
Clinical Server
SOAP Messages
Local Authorization Policies
Master Authorization Poli-
cies
Policy Decision Point
Target
Component
AC
Target Policy
Fig. 4 Access control policies
in MEDIS
J Med Syst (2010) 34:659–666663