Felix Apitzsch
Fraunhofer Institute for Open Communication Systems FOKUS, Kaiserin-Augusta-Allee 31, Berlin, Germany
Stefan Liske, Thomas Scheffler, Bettina Schnor
Department of Computer Science, Potsdam University, Potsdam, Germany
Electronic Health Record (EHR), Security Policies, Digital Rights Language, Privilege Management and Ac-
cess Control (PMAC).
Sensitive data in electronic health records needs marking for special handling in order to maintain privacy.
Person-centred records need mechanisms for individual and flexible 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.
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 first and fore-
The security model proposed in this paper tries not to
ignore or reinvent security or confidentiality 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 specific access control policies.
An important new aspect, that is specific 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., Scheffler T. and Schnor B. (2008).
In Proceedings of the First International Conference on Health Informatics, pages 82-90
mon security architecture has to be applied by any
system involved in the care process and the relevant
components have to comply with well-defined 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).
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 fictional 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.
Reflecting 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 Confidentiality 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 confidentiality 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 specified 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 traffic 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
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
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 specification 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:
<dayOfBirth>1977-09-04 </dayOfBirth>
<event dat e="1988-06-01" time="16:35:27">
<treatment>Chemo therapy</treatment>
<practitioner>DR. AB</pra ctitioner>
<event dat e="2005-08-30" time="10:35:27">
<diagnosis>Gonorrhoea in fection</diagnosis>
<treatment>Ciprofloxacin 500 mg</treatment>
<practitioner>DR. CD</pra ctitioner>
Listing 2: Health Record XML encoded.
The structure of the XML based EHR document
needs to comply with an XML schema definition
(Walmsley, 2004). This way, not only the structure
of an EHR can be unified for simpler post processing,
but specific 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 specific 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
As mentioned for generic XML, CDA supports
a standard XML schema defined structure as well
as specific element tags associated with semantic
concepts. CDA rel. 2 defines seven linked XML
schema definitions, 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 fix vocabulary do-
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 confidentialityCode, can be attached to each of
these objects. Attached to an observation,the attribute
specifies confidentiality 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 confidentiality rules, a confidentialityCode may be
specified at header, body, section, or entry level, each
overwriting the more general.
Confidentiality rules are expressed using the vo-
cabulary domain Confidentiality. 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 defines the confidentiality intentions associated to
the codes, they do not provide sufficient 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 confiden-
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 specification 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 defines its own security model (EN-13606-4,
2007). Using the concepts previously introduced in
part 1 and part 2, part 4 defines 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-
ifications 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 flexible and ex-
tensible archetypes, it is still very limited in the kind
of policies that can be specified. Although EN 13606
is still partly work in progress, it is to be doubted,
that all confidentiality 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 flexible security model is described in the follow-
ing section.
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 definition 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-
fine the semantics of policy composition.
Policy A = (P
) defines 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
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
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 defined. A decision d
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 specific 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 specific pro-
gram code blocks. Hence, a mapping m : Π R
needs to be defined 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
: 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 file. 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
. This means that not everyone
is allowed to set permissions for a resource by defin-
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
) 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
be the owner
of o and let v(ε) be a boolean function that is true, if
and only if
ε : a(p
) = a
: p
) to issue(p
Then v is called verification of authority for ε. If v(ε)
is true, ε is called an authoritative rights expression
and may be used to compute d
. With this definition
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
. 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(ε).
This section compares two prominent policy descrip-
tion languages from the viewpoint of their applicabil-
ity for the application domain.
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 ratified 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 specification. They are needed to
derive an authorisation decision from potentially con-
flicting individual rules and policies. Standard com-
bining algorithms are:
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 refines the applicability of
the rule.
<Rule ... Effect>
Target. The set of resources, subjects and actions
to which rules and policies apply is called a target in
XACML. Targets in policy elements define 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 specified externally.
Version 3.0 is currently in preparation and will add
generic attribute categories and a policy delegation
profile to the XACML specification.
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).
<Policy RuleCombiningAlgId="deny-overrides">
<Rule Effect="Permit">
<ResourceMatch MatchId="xpath-node-equal">
/HealthRecord/fileData </ResourceMatch>
<Rule Effect="Permit">
<Subject>Dr. CD</Subject>
<ResourceMatch MatchId="xpath-node-equal">
<Condition FunctionId="date-less-than-or-equal">
<Apply FunctionId="date-one-and-only"> </Apply>
<demographicInforma tion>
<event date="1988-06-01 16:35:27">
<event date="2005-08-30 10:35:27">
<diagnosis>Gonorrhoea infection</diagnosis>
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 Stefik (Stefik, 1996).
Version 2 of XrML developed at ContentGuard in-
troduces a more generic approach to rights specifica-
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 specific 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 specific 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-
Issuer. The <issuer> tag encloses a set of issuer-
specific 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 specifica-
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 specifies 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
confidentiality 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 specific 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 specific tags, e.g. <hpcHolder> (for
one specific 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-specific
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
<digitalResour ce licensePartId="demoInfo">
[Demographic Info]
</digitalResou rce>
[Traffic Accident]
<digitalResour ce
<[Dr. CD]/ >
<digitalResour ce
<issuer> [Patient] </issuer>
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 efficiently 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.
Explicit issuer No element Element
Condition sup-
Extensive Extensive
Rights delega-
No Yes
X500 naming Supported Not mandatory
X509 identities Not supported Supported
X509 attributes Not supported Not mandatory
Rule-signing Indirectly
through XML
Directly sup-
Encryption of
through XML
Directly sup-
Environment Yes (time, etc.) Yes (time,
ticket, etc.)
Deny rules Yes No
Insertion of ac-
cess rules
Deletion of ac-
cess rules
Policy template
Yes, through
the use of
Type identifiers Not directly Yes, (includes
pattern match-
ing based on
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 define explicit Policy/RuleCombiningAlgo-
rithms for the inclusion of policies from different
Any requirement from Section 2.2 can be ex-
pressed with XrML and XCAML, because there is no
limit to the integration of domain specific 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 defined 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.
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
An open issue and potential basis for further work
is the formulation of a generic set of actions, rich
enough for the fine-grained control over medical data
in the workflow and simple enough for the patient to
reliably apply in EHR policies.
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 Spezifikation der elektro-
nischen Gesundheitskarte. Bundesmin-
isterium für Gesundheit, Version 1.1.0,
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, Specification.
DeRose, J. C. S. (1999). XML Path Lan-
guage (XPath). W3C Recommendation,
Eastlake, D., Reagle, J., and Solo, D. (2002).
RFC3235: Extensible Markup Language - XML-
Signature Syntax and Processing. http://www.rfc-
EN-13606-1 (2007). Health informatics - Electronic
health record communication - Part 1: Reference
model. European Committee for Standardisation,
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.
Stefik, 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-
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,