SPECIFYING SECURITY POLICIES FOR

ELECTRONIC HEALTH RECORDS

Felix Apitzsch

Fraunhofer Institute for Open Communication Systems FOKUS, Kaiserin-Augusta-Allee 31, Berlin, Germany

Stefan Liske, Thomas Schefﬂer, Bettina Schnor

Department of Computer Science, Potsdam University, Potsdam, Germany

Keywords:

Electronic Health Record (EHR), Security Policies, Digital Rights Language, Privilege Management and Ac-

cess Control (PMAC).

Abstract:

Sensitive data in electronic health records needs marking for special handling in order to maintain privacy.

Person-centred records need mechanisms for individual and ﬂexible marking. Policy mechanisms currently

applied with shared health records in integrated care environments lack the ability to model complex privacy

requirements. The paper examines two state-of-the-art policy languages for distributed processing environ-

ments such as web-services and digital rights management and describes how they can be applied with XML

health records. Furthermore, it highlights the abstract concepts that need to be adopted and presents a dis-

tributed policy enforcement model.

1 INTRODUCTION

One of the major problems with integrated care de-

pending on distributed care processes and distributed

health IT is data interoperability between different IT

systems. Centralised health care limited to one hos-

pital and a single episode of illness can be handled

by a single IT system or at least systems operated by

a single authority. With integrated care, health data

needs to be securely available at different locations in

the care process.

The following paper describes how existing stan-

dards for the expression of data access policies for

XML data can be applied to health IT-systems to pro-

tect Electronic Health Records (EHRs). We examine

different EHR standards with respect to their support

for access policies. Afterwards we analyse two policy

languages that can be used to describe access control

for distributed private medical data.

Traditionally, security policies are ﬁrst and fore-

The security model proposed in this paper tries not to

ignore or reinvent security or conﬁdentiality concepts (Blo-

bel et al., 2006) already described inISO 22600, ISO 27799,

ISO 21000, ISO 21731, EN 13606 and EN 13608, but to

combine their views and to present some important com-

mon or extending concepts on an abstracting level.

most bound to a system, not to the resources. Even

though there exist concepts to bind a security pol-

icy primarily to a resource (Wang, 2005), this ap-

proach has not been taken with EHRs yet. Existing

access control methods are tailored towards a cen-

tralised data storage model. Consequently, medical

records are stored in a medical database that is being

accessed from authenticated users. Access control to

the database items would be mediated by the database

itself according to speciﬁc access control policies.

An important new aspect, that is speciﬁc to the

domain of distributed health IT and the use of access

control schemes, is the fact that there is no central

policy management in place. Instead, data owners

themselves should be able to set their own privacy

preferences with the support of default settings and

exemplary templates. These preferences then need to

remain with the data as sticky policies (Mont et al.,

2003)(Karjoth et al., 2003) throughout the ongoing

data distribution process.

In a truly distributed system, medical data can

migrate freely (e.g. on a patients smartcard (BMG,

2006)) and no centralised mechanism exists to protect

access to the data. Therefore, the data has to be self-

contained, which implies that it incorporates the nec-

essary policies and protection mechanisms. A com-

Apitzsch F., Liske S., Schefﬂer T. and Schnor B. (2008).

SPECIFYING SECURITY POLICIES FOR ELECTRONIC HEALTH RECORDS.

In Proceedings of the First International Conference on Health Informatics, pages 82-90

 SciTePress

mon security architecture has to be applied by any

system involved in the care process and the relevant

components have to comply with well-deﬁned stan-

dards. We propose to mediate distributed data access

with the help of explicit policy description languages.

The necessary authentication mechanisms as well

as the mechanisms for the protection of the EHR (e.g.

through encryption) are outside the scope of this pa-

per, but the latter have been addressed in previous

work (Apitzsch, 2007).

2 INTEGRATED CARE USE CASE

In this section we describe an integrated care use case

that serves as the basis for the policy examples de-

scribed in section 4. We present informal privacy re-

quirements for the use case, as well as possible EHR

XML-structures representing its data.

2.1 Shared Use of Medical Data

The following example of a ﬁctional medical history

is constructed to outline relevant characteristics for a

study of privacy requirements. It shows how data of

different sensitivity might be combined in one health

record and different privacy requirements need to be

be addressed by respective privacy policies.

Demographic Information:

Name: John Doe

Date of Birth: 04.09.1977

Place of Birth: Berlin

Medical E ntries:

01.06.1988 - (Dr. AB / XY Clinic)

Diagnosis: Cancer (Le ukaemia)

Treatment: Planned c hemo therapy

10.06.1988 - (Dr. AB / XY Clinic)

Treatment: Chemo therapy

Result: Everything OK

Planned s creening every year

01.07.1989 - (Dr. AB / XY Clinic)

Treatment: Cancer scr eening

Result: Everything OK

[...]

30.08.2005 - (Dr. CD)

Diagnosis: Gonorrhoea infection

Prescription: CIPROF LOXACI N 5 00 mg

15.04.2006 - (Dr. GH / UV Centre)

Diagnosis: Rheumatism

Treatment: Spinal X-r ay

Image: <Attached X-ray>

Prescription: Novalgin

19.07.2006 - (Dr. IJ / ER)

Treatment: X-ray after traffic accident

Image: <Attached X-ray>

Diagnosis: Potential spinal injury

Listing 1: Exemplary Health Record.

Left out in the middle of the report are repetitive

entries about the cancer aftercare. The rheumatism

treatment includes a spinal X-ray that might be help-

ful for the medical opinion on a later potential spinal

injury resulting from a car accident.

The health record addresses the patient’s current situ-

ation with the latest entry for a potential spinal injury

and shows useful X-rays from previous medical ex-

aminations. The further treatment process needs to

add new data to the health record and needs to access

parts of the old data.

Reﬂecting the idea of integrated care, the entries

to the health record were made from different physi-

cian at different and independent institutions, all con-

tributing to the ongoing treatment process for the pa-

tient. Accordingly, each involved computer system

needs to access and process "foreign" data.

When Dr. IJ takes an X-ray to verify a potential

spinal injury he might want to compare it to a prior

spinal X-ray taken in the context of a rheumatism

treatment. This raises the question how he knows

about the prior data and how he can access it. A

straightforward approach would imply that all med-

ical documentation from every individual system is

exported to a common EHR storage, allowing every

party to access any data they need.

Since data from different systems is combined and

leaves the individual security domains, this directly

leads to the question whether everyone should have

access to all medical data and how privacy of medical

data can be preserved.

2.2 Conﬁdentiality Requirements

The following parts of the paper will discuss techni-

cal details of a proposed security solution. Therefore,

this section gives an informal description of exem-

plary security targets for the use case that need to be

addressed in order to preserve privacy of shared med-

ical data.

The listed conﬁdentiality requirements are chosen

to illustrate potential policy issues and even though

commonly reasonable, do not necessarily offer maxi-

mum data protection.

Policy requirements might be different for every

individual patient and under different situations. Con-

sequently, data access privileges speciﬁed by the pa-

tient for the EHR are not static, but need to be dynam-

ically extended or restricted.

In the example, the patient has no privacy con-

cerns regarding the use of demographic data, rheuma-

tism and the trafﬁc accident, that can consequently be

divulged to everyone. Data about cancer and the gon-

orrhoea infection are seen as sensitive and should not

have unlimited access. This requires the ability to ef-

fectively restrict data processing for everyone as cho-

sen by the "owner" of the data, which usually is the

patient.

In this use case example it is therefore not nec-

essary to restrict the use of the rheumatism X-ray

data. The sensitive data about the gonorrhoea in-

fection, however, should only be visible to the EHR

owner (patient). For the attending physician Dr. CD

its visibility should be limited to the time period of

treatment.

2.3 Data Representation in Electronic

Health Records

Even though health records represented as free text

are still in predominant use, standards for structured

data representations in EHRs have been developed

(e.g. (CEN/TS-15211, 2006)). Adding extra infor-

mation on a meta-level, they not only ease data col-

lection, data mining and reuse (cf. (Giere, 1986)) but

additional allow the speciﬁcation of security aspects

at this level.

2.3.1 Genuine XML

Using XML to serialise the medical history described

in Listing 2, the EHR would be structured by tags:

<family_name>Doe</family_name>

<given_name>John</given_name>

</demographicInformation>

<diagnosis>Cancer</diagnosis>

<treatment>Chemo therapy</treatment>

</event>

[...]

<diagnosis>Gonorrhoea in fection</diagnosis>

<treatment>Ciprofloxacin 500 mg</treatment>

</event>

</medicalHistory>

</healthRecord>

Listing 2: Health Record XML encoded.

The structure of the XML based EHR document

needs to comply with an XML schema deﬁnition

(Walmsley, 2004). This way, not only the structure

of an EHR can be uniﬁed for simpler post processing,

but speciﬁc tags or structures can be associated with

semantic concepts.

Moving from free text towards struc-

tured data representation, the segment

<diagnosis>Cancer</diagnosis> could be replaced

with a speciﬁc tag <cancerDiagnosis/> or with

another XML element of the type "cancerDiagnosis".

This approach is used by HL7 CDA and EN13606

which represent the most commonly used and the

latest development of EHR schemata, respectively.

2.3.2 Comments on HL7 CDA

HL7’s Clinical Document Architecture (HL7, 2005)

is not designed to support longitudinal records that

cover complete accumulation of reports over time

similar to the use case example above. A number of

single documents could be used to represent the use

case.

As mentioned for generic XML, CDA supports

a standard XML schema deﬁned structure as well

as speciﬁc element tags associated with semantic

concepts. CDA rel. 2 deﬁnes seven linked XML

schema deﬁnitions, segmenting the XML structure

into header and body, sections and entries. The se-

mantic foundation for the contained elements is the

HL7 Reference Information Model RIM (ISO/HL7-

21731, 2006), complemented with ﬁx vocabulary do-

mains.

The information from the use case example can

be represented by instances of the RIM classes Per-

son, Procedure and Observation. A set of meta-data,

e.g. a conﬁdentialityCode, can be attached to each of

these objects. Attached to an observation,the attribute

speciﬁes conﬁdentiality rules limited to the object it-

self. When present with a person object, it refers to all

entries related to the person. To allow for hierarchi-

cal conﬁdentiality rules, a conﬁdentialityCode may be

speciﬁed at header, body, section, or entry level, each

overwriting the more general.

Conﬁdentiality rules are expressed using the vo-

cabulary domain Conﬁdentiality. It contains the fol-

lowing codes:

• low / normal / restricted / very restricted

• business / clinician / individual / substance abuse

related / HIV related / psychiatry related / sexual

and domestic violence related

• celebrity / sensitive / taboo

The vocabulary domain is a straightforward ap-

proach, but fairly incomplete, as it contains e.g. "HIV

related", but no "cancer related" code. And although

it deﬁnes the conﬁdentiality intentions associated to

the codes, they do not provide sufﬁcient information

to serve as machine processable security policies on

their own. Nevertheless, they can be referred to as

content types by higher level policies.

Additionally the RIM supports the use of roles,

e.g. Patient, Employee, or special access roles. These

might be referred to as types, similar to the conﬁden-

tiality codes.

2.3.3 Comments on En 13606

Even though EN 13606 is a communication standard,

it models the structure of the EHR with a two level

approach, a reference model (EN-13606-1, 2007)

and an archetype model (EN-13606-2, 2005). Us-

ing adequate archetypes, all data from the use case

example can be represented and serialised in XML

conforming to respective schemata (cf. openEHR

(openEHR, 2007) which is an XML-based standard

implementation close to EN 13606). In addition, us-

ing archetypes, which are bound to ontological con-

cepts, semantic meta-information is available for all

entries. This might aid the speciﬁcation of security

policies, as e.g. a cancer-related entry from the use

case can be recognised as such, because it might be

represented as a cancer-archetype.

On top of the reference and archetype model, EN

13606 deﬁnes its own security model (EN-13606-4,

2007). Using the concepts previously introduced in

part 1 and part 2, part 4 deﬁnes an access policy

archetype. (Medical) data that is represented as one

or more COMPOSITIONS is complemented within a

dedicated Access policies FOLDER. Each of these ac-

cess policies itself is represented as a single COMPO-

SITION, whose archetype must conform to the spec-

iﬁcations in part 4 of the standard. Additionally, a

number of security categories are introduced with the

security model:

A Private entries shared with General Practitioner

B Entries restricted to sexual health team

C Entries accessible to administrative staff

D Entries accessible to clinical support staff

E Entries accessible to direct care teams

F Private entries shared with several named parties

G Entries restricted to prison health services

These categories can be used to mark data in an

EN 13606 EHR at different levels of abstraction and

thereby to assign respective policies, cf. Figure 1.

Even though, this pragmatic approach gains some ex-

tra expressiveness through the use of ﬂexible and ex-

tensible archetypes, it is still very limited in the kind

of policies that can be speciﬁed. Although EN 13606

is still partly work in progress, it is to be doubted,

that all conﬁdentiality requirements of the use case

described above, e.g. the delegation of rights, could

be expressed without the integration of more compre-

hensive security standards. Therefore, a more general

Figure 1: Access domains within 13606 EHRs(EN-13606-

4, 2007).

and ﬂexible security model is described in the follow-

ing section.

3 EHR SECURITY MODEL

It is considered good practice to separate policies

and mechanisms for access control and make the pol-

icy explicit. This allows independent implementation

changes to enforcement mechanisms and opens the

policy for external analysis and composition.

3.1 Policy (Description) Languages

From a mathematical point of view an access pol-

icy can be regarded as the set of all possible ac-

cess decisions over the sets of subjects and ob-

jects supported by this policy. A deﬁnition of

such an access policy is given by Woo (Woo and

Lam, 1993): An authorisation policy is the 4-tuple

−

) where each component is a subset

of {(r,s,o)| r ∈ R, s ∈ S,o ∈ O} over the set of sub-

jects S, objects O and access rights R. P

and N

record the rights that are explicitly granted or denied.

Whereas P

−

and N

−

record the rights that should not

be explicitly granted or denied and are needed to de-

ﬁne the semantics of policy composition.

Policy A = (P

−

) deﬁnes three autho-

risation relations for an authorisation request (r,s,o).

Agrants (r,s,o) iff (r,s,o) ∈ P

Adenies (r,s,o) iff (r,s,o) ∈ N

A fails (r,s,o) iff (r,s,o) /∈ P

∪ N

The policy representation as thus becomes irrele-

vant, as long as it can guarantee to be set-theoretical

equivalent to the access matrix.

Policy description languages, such as the eX-

tensible Access Control Markup Language XACML

Figure 2: EHR Processing Model.

(XACML-2.0, 2005) or the eXtensible rights Markup

Language XrML (ContentGuard, 2001) go one step

further in their expressiveness and maintainability

than simple Access Control Lists (ACL).

The ability of these languages to logically group

objects and subjects, as well as the ability to evaluate

environmental conditions, such as access-time, allow

the creation of concise policies. These policies must

be evaluated at the time of access in order to deter-

mine the access decision.

It is to be noted that with the use of these higher

level policy languages the meaning of the term access

decision is being extended. Since the rights that can

be granted by a policy can reference complex process-

ing concepts rather than simple access modes (read-

/write), access control can be replaced by processing

control. Consequently, these terms will be used syn-

onymously, referring to the idea of processing control

via a reference monitor.

3.2 Distributed Processing Control

Architecture

A Reference Monitor is an instance that decides

whether a process associated with the user s ∈ S may

execute a procedure π ∈ Π on a resource o ∈ O under

the current system context c ∈ C. Therefore, it com-

putes its decision for a request ρ = (s,π,o,c) ∈ P =

S× Π× O×C as shown in equation (1).

d : P → {grant, deny} (1)

In a distributed environment a reference monitor

may not know S, Π, O, and C in advance. So, locally,

d cannot be fully be deﬁned. A decision d

dist

needs

to be based on an appropriate security (access) policy.

To make this local decision for the same request ρ in

a distributed environment, a rights expression ε needs

to be evaluated together with the decision request.

The expression ε may describe a number of policies

that explicitly or implicitly address S

× Π

× o × C

for a speciﬁc resource object o. A rights expression

might use the concept of rights R instead of proce-

dures Π. R represents generic action concepts, e.g.

“view” or “amend”, whereas Π contains speciﬁc pro-

gram code blocks. Hence, a mapping m : Π → R

needs to be deﬁned for the actual execution context.

Similarly, with t : O → T the rights expression may

refer to types of objects t(o) rather than the object o

itself. Given a request ρ ∈ P and a rights expression

ε ∈ E, the reference monitor needs to compute

dist

: P× E → {grant, deny} (2)

by matching the decision request against the repre-

sented policies.

In Figure 2 we show the complete processing

model for distributed policy evaluation. The Data

Owner creates a Sticky Policy Object at the Policy Ad-

ministration Point (PAP), which he can also use to

create global policies for all of his EHR data. The

sticky data object combines EHR data with the ac-

tual Access Policy into a single XML ﬁle. It should

be possible to support the policy creation process

through the use of generic policy templates.

Data access from the Data User is only granted

via the Reference Monitor which uses a modularised

design, separating the Policy Enforcement from the

Policy Decision component.

3.3 Sources of Authority

Only authoritative policies may be considered for the

computation of d

dist

. This means that not everyone

is allowed to set permissions for a resource by deﬁn-

ing and issuing arbitrary policies. Only the owner of

a resource may author and authorise policies for it.

Nevertheless, this authority could be extended by the

owner to a third party, e.g. by making the extension

part of a policy that grants the right to grant rights.

The determination of authoritativeness of a policy is

more complicated when privilege delegation or del-

egation of policy authoring is supported by the dis-

tributed processing control architecture.

Let ε = (p

...p

) be a rights expression that con-

sists of a set of policies by different authors a(p

) re-

ferring to a resource o. Further, let a

owner

be the owner

of o and let v(ε) be a boolean function that is true, if

and only if

∀p

∈ ε : a(p

) = a

owner

∨

∃p

i−i

: p

i−1

grantsa(p

) to issue(p

)

(3)

Then v is called veriﬁcation of authority for ε. If v(ε)

is true, ε is called an authoritative rights expression

and may be used to compute d

dist

. With this deﬁnition

the meaning of the term source of authority becomes

clear, as all policy parts in an authoritative rights ex-

pression derive their authority from a single source

owner

. Any policy delegating rights or granting the

right to issue new policies needs to be included in ε to

allow the policy decision point to compute v(ε).

4 XML POLICY LANGUAGES

This section compares two prominent policy descrip-

tion languages from the viewpoint of their applicabil-

ity for the application domain.

4.1 XACML

The eXtensible Access Control Markup Language

(XACML) is a declarative access control policy lan-

guage and a processing model that is standardised by

OASIS (XACML-2.0, 2005). The current version 2.0

was ratiﬁed in 2005.

4.1.1 Language Elements

PolicySet. The <PolicySet> element contains a set

of <Policy> or other <PolicySet> elements and a Pol-

icyCombiningAlgorithm to determine the joint evalu-

ation of different elements.

Policy. The <Policy> element contains a set of rule

elements and a RuleCombiningAlgorithm to deter-

mine the joint evaluation of the rules of the policy.

It is the basis of an authorisation decision.

Combining Algorithms. XACML allows explicit

positive and negative evaluation of rules (permit/-

deny), as well as the combination of policies from

different sources in a PolicySet for distributed pol-

icy generation. Combining algorithms are an essential

part of the language speciﬁcation. They are needed to

derive an authorisation decision from potentially con-

ﬂicting individual rules and policies. Standard com-

bining algorithms are:

• Deny-overrides

• Permit-overrides

• First-applicable

• Only-one-applicable

Rule. The <Rule> element contains a policy expres-

sion that can be evaluated in isolation and providesthe

basic unit of policy management. The main compo-

nents of a rule are its effect (permit/deny), target and

potentially a condition that reﬁnes the applicability of

the rule.

...

</Target>

...

</Condition>

</Rule>

Target. The set of resources, subjects and actions

to which rules and policies apply is called a target in

XACML. Targets in policy elements deﬁne the scope

of this element. If no restrictions have been made here

the policy will have global scope.

Issuer/Delegation. As of version 2.0, XACML pro-

vides no mechanisms to describe a delegation policy

as well as an issuer of a policy/delegation. In the

current standard these have to be speciﬁed externally.

Version 3.0 is currently in preparation and will add

generic attribute categories and a policy delegation

proﬁle to the XACML speciﬁcation.

4.1.2 Use Case Example

The XACML approach strictly separates authorisa-

tion policies and resources. Within XML-based re-

sources policies can be included and referenced via

XPath (DeRose, 1999).

/HealthRecord/fileData </ResourceMatch>

</Resources>

</Target>

</Rule>

/HealthRecord/medHistory/event[Diagnosis="Gonorrhoea"]

</ResourceMatch>

</Resources>

</Condition>

</Target>

</Rule>

</Policy>

[...]

</fileData>

<diagnosis>Cancer</diagnosis>

[...]

</event>

<diagnosis>Gonorrhoea infection</diagnosis>

[...]

</event>

</medHistory>

</HealthRecord>

Listing 3: XACML Policy protected EHR.

4.2 XrML / MPEG-21

The origin of XrML is research on a "digital rights

property language" (DPRL) by Steﬁk (Steﬁk, 1996).

Version 2 of XrML developed at ContentGuard in-

troduces a more generic approach to rights speciﬁca-

tions. A revised edition was adopted by ISO as part

5 of the MPEG-21 standard. All subsequent state-

ments refer to the MPEG-21 Version of XrML. Rights

and other properties are represented by abstract con-

cepts that are not bound to any context domain. Us-

ing XML namespaces, this basic XML structure can

be extended with domain speciﬁc language elements

replacing the abstract concepts. Therefore, it can be

assumed that XRML can be adapted to the context of

EHRs, a hypothesis that will be substantiated below.

4.2.1 Language Elements

License. A license in terms of XrML is a collec-

tion of grants allowing individuals to perform ac-

tions on speciﬁc resources. The <license> tag is the

root of the XML tree and brackets all other relevant

tags including <grant> or <grantGroup>, <issuer> and

<inventory>. It does not contain any processible in-

formation itself. Alternatively, the non-obfuscated

child nodes of a license can be replaced by an

<encryptedLicense> which contains the same infor-

mation, but needs to be decrypted for further process-

ing.

Issuer. The <issuer> tag encloses a set of issuer-

speciﬁc details about the circumstances under which

he issues the license and a digital signature (Eastlake

et al., 2002) for the license. With respect to the use

case it could be the patient as a single source of au-

thority signing the license.

Inventory. The <inventory> tag marks a part of a

license that can be used to store anything referred to

by a grant. By placing it in the inventory, redun-

dancy, e.g. multiple principal or resource speciﬁca-

tions, can be avoided when multiple grants refer to

the same items. With respect to the use case, the in-

ventory would be the place to include XML fragments

of the EHR within <digitalResource> subsections, or

to give an URI reference to an external EHR resource.

Grant or GrantGroup. Multiple subsections

marked by <grant> tags may be present. A grant

is the part of the license that speciﬁes information

relevant to decide whether a sub-procedure within a

computer program should be executed with respect

to the license (issuer’s intention) or not. Like the

<license>, the <grant> tag is only of syntactical

nature. The relevant information is contained in the

quartet of child nodes for principal, right, resource

and condition, which all are conceptually abstract.

For each grant, additional pattern and delegation-

control information can be stored in <forAll> and

<delegationControl> tags respectively.

Therefore and with respect to the use case, the

conﬁdentiality requirements from Section 2.2 can be

represented in the grant sections, including the in-

tended delegation of privileges.

Principal, Right, Resource, Condition. Within

each grant domain speciﬁc tags represent the ab-

stract concepts principal, right, resource and condi-

tion. This means that there are no <principal> or

<right> tags, but that these concepts can be substi-

tuted with domain speciﬁc tags, e.g. <hpcHolder> (for

one speciﬁc holder of a health professional card) or

<compareImage> (indicating the X-rays from the use

case may be compared). These extensions to the

abstract concepts are assembled in domain-speciﬁc

XML-namespaces.

4.2.2 Use Case Example

The following code lists in an abridged form the re-

quired XrML language elements for the EHR use case

example.

<XML>

[Demographic Info]

</XML>

</digitalResou rce>

[Cancer01]

[...]

[Gonorrhoea]

[...]

[Traffic Accident]

</inventory>

<grant>

<digitalResour ce

licensePartRef="demoInfo">

</grant>

[...]

<grant>

<[Dr. CD]/ >

<view/>

<digitalResour ce

licensePartRef="gonorrhoea">

</grant>

[...]

<issuer> [Patient] </issuer>

</license>

Listing 4: XrML Policy protected EHR.

4.3 Comparison of XACML and XrML

Policy description languages differ in their ability to

express certain concepts directly and efﬁciently as

part of their language. Table 1 compares the support

for different concepts in XACML and XrML.

Any XrML license is always granting. There are

no denying syntax elements in the language. There-

fore, the absence of a license never leads to false pos-

Table 1: Comparison between XACML and XrML.

XACML XrML

Explicit issuer No element Element

Condition sup-

port

Extensive Extensive

Rights delega-

tion

No Yes

X500 naming Supported Not mandatory

X509 identities Not supported Supported

X509 attributes Not supported Not mandatory

Rule-signing Indirectly

through XML

signatures

Directly sup-

ported

Encryption of

content

Indirectly

through XML

encryption

Directly sup-

ported

Environment Yes (time, etc.) Yes (time,

ticket, etc.)

Deny rules Yes No

Insertion of ac-

cess rules

Easy

Deletion of ac-

cess rules

Easy

Policy template

support

Yes, through

the use of

PolicySets

Type identiﬁers Not directly Yes, (includes

pattern match-

ing based on

XPath)

might lead to changes in the policy (grant/deny rules)

itive granting. This might be an advantage in dis-

tributed systems. XACML Policies instead have the

ability to express negative authorisations and there-

fore can deﬁne explicit Policy/RuleCombiningAlgo-

rithms for the inclusion of policies from different

sources.

Any requirement from Section 2.2 can be ex-

pressed with XrML and XCAML, because there is no

limit to the integration of domain speciﬁc concepts.

Domain independent requirements, e.g. the delega-

tion of privileges, are featured by XrML itself.

Furthermore, the languages can express all ele-

ments of rights expression, as deﬁned in the general

security model in Section 3.2. The computation of

m(r) is in the responsibility of the policy enforcement

point, referring to t(o) is directly supported by XrML.

e.g., it can refer to HL7 RIM attributes or EN13606

archetype using resourcePatterns.

5 CONCLUSIONS

In this paper we have examined the possibility to use

existing XML policy languages that were developed

for digital rights management and the description of

access policies for the protection of EHR data.

We foresee a need to mediate distributed data ac-

cess, where data is stored, accessed and processed in

a truly distributed fashion without the help of cen-

tralised policy mechanisms. Distributed data access,

however, also requires a dedicated access control ar-

chitecture, which we presented in Section 3 as a gen-

eral model for access control in distributed processing

environments, e.g. the medical IT environment de-

scribed in the use case. Any concrete implementation

of an policy enforcement mechanism can be analysed

and compared with respect to this model.

The analysis of current EHR standards has shown

that they are not ideally suited for reliable data pro-

tection and patient-controlled access restrictions. In-

stead, they should be used in combination with dedi-

cated policy languages.

Section 4 presents two dedicated policy descrip-

tion languages that might be used to specify data ac-

cess policies for EHR. A structural analysis and short-

ened example explains how these languages could be

used. Even though a full policy description repre-

senting the use case could not be given for reasons

of readability and length, their general applicability is

shown. The two languages are compared face to face,

outlining important differences when used for EHR

protection.

An open issue and potential basis for further work

is the formulation of a generic set of actions, rich

enough for the ﬁne-grained control over medical data

in the workﬂow and simple enough for the patient to

reliably apply in EHR policies.

REFERENCES

Apitzsch, F. (2007). Digital Rights Management for Elec-

tronic Health Records. In Proceedings of CeHR Inter-

national Conference 2007 (to appear).

Blobel, B., Nordberg, R., Davis, J., and Pharow, P. (2006).

Modelling privilege management and access control.

In International Journal of Medical Informatics, vol-

ume 75, pages 597–623.

BMG (2006). Die Speziﬁkation der elektro-

nischen Gesundheitskarte. Bundesmin-

isterium für Gesundheit, Version 1.1.0,

http://www.dimdi.de/static/de/ehealth/karte/index.htm.

CEN/TS-15211 (2006). Health informatics - Mapping of

hierarchical message descriptions to XML. European

Committee for Standardisation, http://www.cen.eu.

ContentGuard (2001). eXtensible rights Markup Language

(XrML) 2.0, Speciﬁcation.

DeRose, J. C. S. (1999). XML Path Lan-

guage (XPath). W3C Recommendation,

http://www.w3.org/TR/1999/REC-xpath-19991116.

Eastlake, D., Reagle, J., and Solo, D. (2002).

RFC3235: Extensible Markup Language - XML-

Signature Syntax and Processing. http://www.rfc-

editor.org/rfc/rfc3275.txt.

EN-13606-1 (2007). Health informatics - Electronic

health record communication - Part 1: Reference

model. European Committee for Standardisation,

http://www.cen.eu.

EN-13606-2 (2005). Health informatics - Electronic health

record communication - Part 2: Archetypes. European

Committee for Standardisation, http://www.cen.eu.

EN-13606-4 (2007). Health informatics - Electronic health

record communication - Part 4: Security. European

Committee for Standardisation, http://www.cen.eu.

Giere, W. (1986). BAIK - Befunddokumentation und Arzt-

briefbeschreibung im Krankenhaus.

HL7 (2005). HL7 Clinical Document Architecture, Release

2.0, Normative Edition.

ISO/HL7-21731 (2006). Health informatics - HL7 version

Reference information model Release 1).

Karjoth, G., Schunter, M., and Waidner, M. (2003).

Platform For Enterprise Privacy Practices: Privacy-

enabled Management Of Customer Data. In

2nd Workshop on Privacy Enhancing Technologies

(PET2002), volume Lecture Notes in Computer Sci-

ence 2482, pages 69–84. Springer Verlag.

Mont, M. C., Pearson, S., and Bramhall, P. (2003). To-

wards Accountable Management of Identity and Pri-

vacy: Sticky Policies and Enforceable Tracing Ser-

vices. In Proceedings of the 14th International Work-

shop on Database and Expert Systems Applications,

page 377. IEEE Computer Society.

openEHR (2007). openEHR Release 1.0.1.

http://www.openehr.org.

Steﬁk, M. (September 18th, 1996). The Digital Property

Rights Language, Manual and Tutorial, Version 1.02.

Technical report, Xerox Palo Alto Research Center,

Palo Alto, CA.

Walmsley, D. C. F. P. (2004). XML Schema. W3C

Recommendation, http://www.w3.org/TR/2004/REC-

xmlschema-0-20041028/.

Wang, X. (2005). Desing Principles and Issues of Rights

Expression Languages for Digital Rights Manage-

ment. In Proceedings SPIE, Conference on Vi-

sual Communications and Image Processing, volume

5960, pages 1130–1141.

Woo, T. Y. C. and Lam, S. S. (1993). Authorizations in

Distributed Systems: A New Approach. Journal of

Computer Security, 2(2-3):107–136.

XACML-2.0 (2005). eXtensible Access Control

Markup Language (XACML). OASIS-Standard,

http://www.oasis-open.org/committees/xacml.