On a Formal and User-friendly Linguistic Approach to

Access Control of Electronic Health Data

Andrea Margheri

, Massimiliano Masi

, Rosario Pugliese

and Francesco Tiezzi

Universit

a di Firenze, Viale Morgagni 65, 50134 Firenze, Italy

Tiani “Spirit” GmbH, Guglgasse 6, 1110 Vienna, Austria

IMT Advanced Studies Lucca, Piazza S. Ponziano 6, 55100 Lucca, Italy

Keywords:

Data Security, Electronic Health Records, Access Control.

Abstract:

The importance of the exchange of Electronic Health Records (EHRs) between hospitals has been recognized

by governments and institutions. Due to the sensitivity of data exchanged, only mature standards and im-

plementations can be chosen to operate. This exchange process is of course under the control of the patient,

who decides who has the rights to access her personal healthcare data and who has not, by giving her per-

sonal privacy consent. Patients’ privacy consent is regulated by local legislations, which can vary frequently

from region to region. The technology implementing such privacy aspects must be highly adaptable, often

resulting in complex security scenarios that cannot be easily managed by patients and software designers. To

overcome such security problems, we advocate the use of a linguistic approach that relies on languages for

expressing policies with solid mathematical foundations. Our approach bases on FACPL, a policy language

we have intentionally designed by taking inspiration from OASIS XACML, the de-facto standard used in all

projects covering secure EHRs transmission protected by patients’ privacy consent. FACPL can express poli-

cies similar to those expressible by XACML but, differently from XACML, it has an intuitive syntax, a formal

semantics and easy to use software tools supporting policy development and enforcement. In this paper, we

present the potentialities of our approach and outline ongoing work.

1 INTRODUCTION

Since the early 60s, provision of healthcare has grad-

ually evolved towards the so-called electronic health-

care (e-Health). E-Health aims at improving the ef-

fectiveness of healthcare by resorting to information

systems for storing and exchanging patient data in

form of Electronic Health Records (EHRs). However,

despite the many achievements attained in this ﬁeld

so far, only in recent years governments have started

to signiﬁcantly invest on initiatives and projects aim-

ing at providing (cooperative and interoperable) e-

Health solutions to their citizens. For example, in

1996, U.S.A. senators E. Kennedy and N. Kassebaum

sponsored the Health Insurance Portability and Ac-

countability Act (HIPAA), with the goal of protect-

ing “health insurance coverage for workers and their

families when they change and lose their jobs” and

requiring “the establishment of national standards for

electronic healthcare transactions and national iden-

tiﬁers for providers, health insurance plans and em-

ployers” (Kennedy and Kassebaum, 1996). More re-

cently, the exchange of EHRs among clinics and hos-

pitals has been pursued by the European Commis-

sion with the Standardisation Mandate 403 (EU Com-

mission, 2007), aiming at providing a set of estab-

lished standards for secure EHR access and commu-

nication to the ICT industry. An example of project

funded in response to this EU directive is epSOS (The

epSOS project, 2007). Its goal is to create a pan-

European network for exchanging patient summaries

and ePrescriptions/eDispensations among participat-

ing nations. To this aim, epSOS went far beyond

the state-of-the-art, by choosing and contributing to

the development of international standards for secu-

rity, communication protocols, and data representa-

tion (see, e.g., (OASIS Security Services TC, 2005;

OASIS Web Services Security TC, 2009; The IHE

Initiative, 2009; Health Level Seven organization,

2009; Bittins and Masi, 2011)).

The need of deﬁning such standards is of crucial

importance in the ﬁeld of e-Health, due to both the

high-level of sensitivity of patients private data, the

high impact that a security ﬂaw can have in the life of

263

Margheri A., Masi M., Pugliese R. and Tiezzi F..

On a Formal and User-friendly Linguistic Approach to Access Control of Electronic Health Data.

DOI: 10.5220/0004328202630268

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2013), pages 263-268

ISBN: 978-989-8565-37-2

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

patients, and the need of harmonizing different coun-

try legislations on patients’ privacy consent and en-

abling their healthcare systems to interoperate.

In this paper, we focus on the problem of deﬁn-

ing and implementing access control policies for pro-

tecting EHRs from accesses by unauthorized users

(i.e. people not explicitly authorized by patients).

The challenge comes from the necessity of adopting

a standard-based approach and, at the same time, of

providing policy designers with tools that permit writ-

ing access control policies in a user-friendly way and

enable formal reasoning on them. This latter aspect

would be a remarkable achievement, since it would

permit to formally enforce patients’ informed privacy

consent by supporting policy designers and system ar-

chitects (and, indirectly, also patients, healthcare pro-

fessionals and lawyers) to understand the overall ef-

fect of policies and their consequences.

We propose an approach inspired by the OA-

SIS standard eXtensible Access Control Markup Lan-

guage (XACML) (OASIS XACML TC, 2005), which

is the de-facto standard for deﬁning authorization

statements to protect sensible resources. For example,

also the epSOS’s standardization bodies endorsed its

use for guaranteeing a secure and authorized access

to patient health data by enforcing the informed pri-

vacy consent. However, the adoption of XACML may

imply a high cost. Indeed, XACML comes with an

XML syntax that makes the task of writing (and, then,

understanding) policies difﬁcult and error-prone. Be-

sides, it comes without a formal semantics, rather its

speciﬁcation document is written in prose (i.e., in En-

glish) and contains quite a number of loose points that

may give rise to different interpretations and lead to

different implementation choices. This leaves the dif-

ﬁcult task of understanding the full implications of the

various choices to the implementers, which should be

avoided, since otherwise the portability of XACML

policies across different platforms could be consider-

ably undermined.

To address the issues above concerning XACML,

we advocate the use of Formal Access Control Pol-

icy Language (FACPL) (Masi et al., 2012). FACPL

is a language for expressing policies with solid math-

ematical foundations but, differently from XACML,

its simple and clear syntax and semantics makes it

easy to learn and use. Indeed, FACPL comes with

a BNF syntax that can be exploited to create front-

ends for user-friendly policy editors. Besides, since

FACPL relies on theoretical foundations, it enables

formal reasoning on policies to be used, e.g., for for-

mally proving patient consent, law fulﬁllment and

other soundness properties. We have intentionally de-

signed FACPL by taking inspiration from XACML,

thus it can express access control policies similar to

those expressible by XACML and for different appli-

cation domains. In this paper, however, we focus on

the healthcare domain and present the potentialities of

our approach when used in healthcare systems in pro-

duction where we believe it can contribute to build

safer and more reliable systems.

The rest of the paper is organized as follows. Sec-

tion 2 provides an overview of XACML by resorting

to an application to an healthcare scenario borrowed

from epSOS. Section 3 presents FACPL and the tools

already developed on top of it. Finally, Section 4 con-

cludes the paper by discussing the potentialities of the

proposed formal approach.

2 THE XACML STANDARD

The XACML standard provides a language for ex-

pressing access control policies and access requests,

and a framework to evaluate access requests w.r.t.

policies and to enforce the authorization decision.

The access to each resource is regulated by one or

more policies. These are XML documents expressing

the capabilities and credentials that a requestor must

have for accessing the resource.

Evaluation of XACML requests is performed by

two different actors, the Policy Decision Point (PDP)

and the Policy Enforcement Point (PEP). The autho-

rization decision is computed by the PDP by checking

the matching between values speciﬁed in the policies

and the corresponding values retrieved from the re-

quests. The decision can be one among permit, deny,

not-applicable and indeterminate: the ﬁrst two values

have an obvious meaning, while the third means that

the PDP does not have any policy that applies to the

request and the fourth means that the PDP is unable to

evaluate the request. In case of permit and deny, the

PDP can attach some additional actions, called obli-

gations, to the decision. The PDP decision is then

enforced by the PEP, which authorizes the access re-

quest if it understands and can discharge the obliga-

tions and, of course, if the PDP decision is positive.

The basic elements of the policy language pro-

vided by the standard are the rules. A rule speci-

ﬁes the logic for the access control decision by means

of an effect, that can be either permit or deny; a tar-

get, that indicates to which requests the rule applies;

a condition, that is an expression reﬁning the appli-

cability established by the target; and some obliga-

tions. Rules are then combined into policies that, be-

sides their own target and obligations, specify a com-

bining algorithm, which, from the set of rules’ de-

cisions, computes what is the decision for a request.

HEALTHINF2013-InternationalConferenceonHealthInformatics

264

Finally, policies can be combined into policy sets that,

again, specify a combining algorithm, a target and

some obligations.

As an example, consider the policy in Listing 1

expressing (an excerpt of) the patient’s privacy con-

sent for the epSOS project. In this project, each role

(e.g., physician, nurse, pharmacist) has permissions

for performing a certain action (e.g., read or write)

on a resource (e.g., code 34133-9 identiﬁes a patient

summary) for a certain purpose (e.g., healthcare treat-

ment, statistics, emergency).

Listing 1: epSOS patient consent in XACML (excerpt).

<P o l i c y Po l i c y I d = ” summary ” . . .

RuleCom b i n i n g A l g I d = ” . . . : r u l e −combining−

a l g o r i t h m : p e r m i t −o v e r r i d e s ”>

<AnyOf>

<A t t r i b u t e V a l u e> TREATEMENT </ A t t r i b u t e V a l u e>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −ca t e g o r y : s u b j e c t ”

A t t r i b u t e I d = ” . . . s u b j e c t: p ur p o s e o f us e ” />

</ Match>

</ A l l O f>

</ AnyOf>

<AnyOf>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −ca t e g o r y : s u b j e c t ”

A t t r i b u t e I d = ” . . . : s u b j e c t : r o l e ” />

</ Match>

</ A l l O f>

</ AnyOf>

<AnyOf>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −c at e g o r y :r e s o u r ce ”

A t t r i b u t e I d = ” . . . : r e s o ur c e : r e s o u r c e −i d ” />

</ Match>

</ A l l O f>

</ AnyOf>

</ Ta r get>

<AnyOf>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −ca t e g o r y : a c t i o n ”

A t t r i b u t e I d = ” . . . : a c t i o n : a c t i o n −i d ” />

</ Match>

</ A l l O f>

</ AnyOf>

</ Ta r get>

</ Apply>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −ca t e g o r y : s u b j e c t ”

A t t r i b u t e I d = ” . . . : s u b j e c t : h l 7 : p e r m i s s i o n ” />

</ Apply>

</ C o nd i t i on>

</ Rule>

</ Rule>

<Ob l ig a t i o n E x p re s s i o n F u l f i l l O n = ” Per m it ”

O b l i g a t i o n I d = ” . . . : o b l i g a t i o n : l o g ”>

<At tr i b u te A s s ig n m e nt E x p re s s i o n

A t t r i b u t e I d = ” . . . : a t t r i b u t e : s u b j e c t ”>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −ca t e g o r y : s u b j e c t ”

A t t r i b u t e I d = ” . . . : s u b j e c t : p h y s i c i a n −i d ” />

</ A t t r i b u t e V a l u e>

</ A t t r ib u t e As s i g nm e n t Ex p r e ss i o n>

<At tr i b u te A s s ig n m e nt E x p re s s i o n

A t t r i b u t e I d = ” . . . : a t t r i b u t e : r e s o u r c e ”>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −c at e g o r y :r e s o u r ce ”

A t t r i b u t e I d = ” . . . : r e s o ur c e : r e s o u r c e −i d ” />

</ A t t r ib u t e As s i g nm e n t Ex p r e ss i o n>

</ O b l i g a ti o n E x p r e s si o n>

<Ob l ig a t i o n E x p re s s i o n F u l f i l l O n = ” Deny ”

O b l i g a t i o n I d = ” . . . : o b l i g a t i o n : m a i l ”>

<At tr i b u te A s s ig n m e nt E x p re s s i o n

A t t r i b u t e I d = ” . . . : a t t r i b u t e : m a i l t o ”>

<A t t r i b u t e D e s i g n a t o r

Category = ” . . . : a t t r i b u t e −c at e g o r y :r e s o u r ce ”

A t t r i b u t e I d = ” . . . :r e s o ur ce : r e so uc e−i d : e m a i l ” />

</ A t t r ib u t e As s i g nm e n t Ex p r e ss i o n>

<At tr i b u te A s s ig n m e nt E x p re s s i o n

A t t r i b u t e I d = ” . . . : a t t r i b u t e : t e x t ”>

Your med i c al re co r d has been r equest e d by

EpSOS s u b j e c t

</ A t t r i b u t e V a l u e>

</ A t t r ib u t e As s i g nm e n t Ex p r e ss i o n>

</ O b l i g a ti o n E x p r e s si o n>

</ O b l i g a t i o n E x p r e ss i on s>

</ P o l i c y>

The policy speciﬁes a subject and a resource in its tar-

get, according to which the policy applies to requests

issued by a physician with the purpose of accessing

to a resource with a code identiﬁer 34133-9 for an

healthcare TREATMENT. If these capabilities are met,

the rules enclosed in the policy are evaluated. The

ﬁrst rule has effect Permit if the requestor aims at per-

forming a Read action and has at least the permis-

OnaFormalandUser-friendlyLinguisticApproachtoAccessControlofElectronicHealthData

265

sions PRD-003, PRD-005, PRD-010, and PRD-016

for accessing the resource. The second rule has al-

ways effect Deny and is combined with the previous

one in such a way that if the ﬁrst rule evaluates to Per-

mit then the policy permits the access to the resource,

otherwise the access is denied (combining algorithm

permit-overrides). Concerning the obligations, if an

access request is evaluated as permit, a log entry about

the requestor and the resource is recorded in the sys-

tem, while if the decision is deny an e-mail is sent to

the patient to notify the (unauthorized) attempt.

As witnessed by the code in Listing 1, the XML

syntax makes it hard to identify the relevant pol-

icy features, especially for users not familiar with

XACML but that anyhow need to understand the over-

all effect of combined policies.

3 THE FACPL APPROACH

The language FACPL provides a manageable alterna-

tive syntax to XACML through a BNF-like grammar.

It is indeed a tiny language that is easy to learn and ca-

pable of expressing XACML policies in a very com-

pact and readable way. For example, the XACML

policy reported in Listing 1 can be rewritten in FACPL

as shown in Listing 2.

Listing 2: epSOS patient consent in FACPL.

<pe rmi t−o v e r r i d e s ;

t a r g e t :

s t r i n g −equal ( ”TREATEMENT” , su b j e c t / purposeofuse )

and s t r i n g −equal ( ” ph y s i ci a n ” , su b j e c t / r o l e )

and s t r i n g −equal ( ”34133−9 ” , r e sou rce / resourc e−i d ) ;

r u l e s :

( per m it ;

t a r g e t : s t r i n g −eq ua l ( ” Read ” , ac t i o n / a c t io n−i d ) ;

c o n d i t i o n :

s t r i n g −subs e t ( s t r i n g −bag ( ”PRD−003” , ”PRD−005” ,

”PRD−010” , ”PRD−016” ) ,

s u b j e c t / h l 7 : p e r m i s s i o n ) ; o b l : ; )

( deny ; t a r g e t : ; c o n d i t i o n : ; o b l : ; ) ;

o b l :

( per m it ; M;

lo g ( su b j e c t / p hy si ci an−id , re sour ce / resource−i d ) )

( deny ; M;

ma il ( re s our c e / resource−i d . email , ” Your medical r ec o r d

has been r equest e d by EpSOS s u b j e c t ” ) ) ; >

The above code demonstrates that the FACPL nota-

tion, compared to that of XACML, is simpler and

more intuitive. It is worth noticing that a FACPL

policy is denoted by a structured term, surrounded

by angular brackets, that speciﬁes a combining algo-

rithm, a target, a set of rules, and a set of obligations.

A FACPL rule is surrounded by round brackets and

has a similar structure, but for the algorithm replaced

by the effect and for the enclosed rules replaced by

a condition. Notably, FACPL targets are not de-

ﬁned according to the structure <AnyOf>-<AllOf>-

<Match>, rather are simply boolean expressions (i.e.

conjunctions and disjunctions of matching functions).

Finally, FACPL obligations are triples specifying an

effect, a type (M for mandatory and O for optional

and an action to be performed by the PEP.

The formal semantics of FACPL policies is given

in a denotational style, i.e. it is deﬁned by a func-

tion [[·]]

that, given a policy/policySet and a set R of

access requests, returns a decision tuple of the form

h permit : {< r

, Obl

i∈I

deny : {< r

, Obl

j∈I

not-applicable : R

indeterminate : R

where {r

}

i∈I

, {r

}

j∈I

, R

and R

form a partition

of R according to the results of the requests’ evalua-

tion. Requests in the permit and deny sets may have

attached sets of obligations. A decision tuple repre-

sents the evaluation result computed by the PDP and

passed as input to the PEP for its evaluation. The ﬁ-

nal result does not contain obligations, as they are dis-

charged during the enforcement process by the PEP.

An example of a FACPL request for accessing a

patient summary is reported in Listing 3.

Listing 3: Patient summary request.

Reques t :{Request1

( su b j e c t / purposeofuse , ”TREATEMENT” )

( su b j e c t / r o l e , ” p h y s i ci a n ” )

( su b j e c t / p h y s i c ia n−id , ” jh1234 ” )

( su b j e c t / h l 7 : p e r m i s s i on , ”PRD−003 ” )

( su b j e c t / h l 7 : p e r m i s s i on , ”PRD−005 ” )

( su b j e c t / h l 7 : p e r m i s s i on , ”PRD−010 ” )

( su b j e c t / h l 7 : p e r m i s s i on , ”PRD−016 ” )

( re s our c e / resource−id , ” 34133−9 ” )

( re s our c e / resource−i d . email , ” pa ti e nt @ mai l . com” )

( a c t i o n / a c ti o n −id , ” Read ” )

}

The request is made by the physician with personal

identiﬁer jh1234 for reading the health record of a pa-

tient for treatment purposes. Given this request and

the policy in Listing 2, the FACPL semantics returns

a decision tuple where the permit set consists of a pair

formed by the request and the obligation requiring the

log update.

We have seen so far that FACPL permits devel-

oping access control policies which are intuitive and

easy to read, write and understand. In order for

In XACML jargon, the optional obligations are called

advices.

HEALTHINF2013-InternationalConferenceonHealthInformatics

266

Figure 1: FACPL development environment.

FACPL to be actually used for dealing with real sys-

tems, a software architecture for evaluating access re-

quests and software tools supporting policy develop-

ment are necessary.

Therefore, FACPL semantics has been imple-

mented in Java as a sort of “compiler” that transforms

FACPL policies into Java classes following the se-

mantics rules deﬁned in (Masi et al., 2012). Simi-

larly, an access request is compiled into a Java

class.

A policy decision is then computed by executing the

generated policy code with the request code passed as

parameter to an entry method.

Moreover, FACPL has been equipped with a dedi-

cated powerful Integrated Development Environment

(IDE), implemented as an Eclipse

plug-in

by means

of the Xtext framework

. The FACPL IDE supports

users in the process of developing policies by means

of such features as code auto-completion, syntax

checks, generation of XACML code and, of course,

generation of Java code by means of the library men-

Java 1.6 or higher. http://www.java.com

Eclipse Juno 4.2. http://www.eclipse.org/

To install the FACPL plug-in it is sufﬁcient

to open Eclipse, click on Help>Install New Soft-

ware. . . and follow the wizard, by specifying the URL

http://rap.dsi.uniﬁ.it/xacml tools/facpl/FacplEclipsePlugin/

when requested.

Xtext 2.3. http://www.eclipse.org/Xtext/

tioned above. A screenshot of the IDE, showing two

epSOS’s policies for ePrescription and patient sum-

mary, is reported in Figure 1.

4 CONCLUDING REMARKS

We presented the use of a policy language with solid

mathematical foundations for the deﬁnition of pa-

tients’ privacy consent in healthcare projects. Our

approach relies on FACPL, a language inspired by

OASIS XACML 3.0. We have seen that FACPL for-

mal semantics is more helpful than XACML natural

language descriptions for understanding the behav-

ior of the authorization process. Besides, it is an ef-

fective guide for the implementation of the language

and paves the way for the development of analysis

tasks, such as policy comparison, policy veriﬁcation

and policy querying.

For example, equivalences and preorders among

different policies could be a ﬁrst target achievable

by means of FACPL formal semantics. This is par-

ticularly helpful in the scope of the epSOS project,

which actually counts 23 participating countries and

some new non-EU countries are foreseen. From

a technological standpoint, epSOS’ challenges were

mostly related to the harmonization of all the Euro-

pean countries’ legislations for handling patients’ pri-

OnaFormalandUser-friendlyLinguisticApproachtoAccessControlofElectronicHealthData

267

vacy consent. In fact, the goal of epSOS in this area

was to follow the suggestions of the EU Article 29

WP (Directorate-General of Justice, 2010), and to let

each member state deﬁne patients’ consent following

the national legislation. These facts have been re-

ﬂected in the establishment of the epSOS Circle of

Trust (CoT), a Service Level Agreement (SLA) signed

by countries in order to securely share data in the ep-

SOS network. In fact, due to the high level of sensitiv-

ity of patient’s private data exchanged, and to the high

impact that a security ﬂaw can have in terms of break-

ing the CoT, only mature and well-known standards

are allowed in the scope of the project. Therefore, all

the policies in epSOS are written using XACML.

FACPL mathematical foundations enable each

participating nation to formally prove the SLA ful-

ﬁllment of its policies for privacy consent (written in

agreement with the respective local legislation) thus

guaranteeing the country’s participation in the CoT.

In fact, various analysis on the policies can be per-

formed. For example, equivalence analysis, which is

already enabled by FACPL formal semantics, could

be used to prove that each policy follows the epSOS

requirements expressed by means of a continent-wide

referenced XACML policy.

To reduce lacking design, a constraint system for

validating the behavior of the authorization process

could be deﬁned. To this aim, we will design a practi-

cal way to deﬁne safety and coverage properties over

an access control system model. These properties

are useful for one of the most difﬁcult problem for

policy-based access control systems: to understand

the overall effect of combined policies evaluation or

the unexpected consequences on obligation discharg-

ing. For example, inaccurate policies might uninten-

tionally override patient consent, thus possibly autho-

rizing an intruder to access. This type of analysis is

known as change-impact analysis and is usually car-

ried on by means of a formal logic, as e.g. a descrip-

tion logic. It has many practical applications, among

which examining differences between policy versions

and identifying redundant policies.

To assess the effectiveness of FACPL and its re-

lated tools and techniques, we plan both to experiment

with healthcare systems in production and to also con-

sider case studies from other domains.

ACKNOWLEDGEMENTS

This work has been partially sponsored by the EU

project ASCENS (257414).

REFERENCES

Bittins, S. and Masi, M. (2011). Cross community fetch.

http://www.ihe.net.

Directorate-General of Justice (2010). Article 29 working

party: documents.

EU Commission (2007). Mandate 403 en: Standardi-

sation mandate addressed to cen, cenelec and etsi

in the ﬁeld of information and communication tech-

nologies. Technical report, European Commis-

sion Enterprise And Industry Directorate-General.

http://www.ehealth-interop.eu.

Health Level Seven organization (2009). Hl7 standards.

http://www.hl7.org.

Kennedy, E. and Kassebaum, N. (1996). Health insurance

portability and accountability act. Technical report,

US Congress. http://www.cms.gov/HIPAAGenInfo.

Masi, M., Pugliese, R., and Tiezzi, F. (2012). Formalisa-

tion and implementation of the xacml access control

mechanism. In Barthe, G., Livshits, B., and Scandari-

ato, R., editors, ESSoS, volume 7159 of Lecture Notes

in Computer Science, pages 60–74. Springer.

OASIS Security Services TC (2005). Assertions

and protocols for the OASIS security assertion

markup language (SAML) v2.02. http://docs.oasis-

open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

OASIS Web Services Security TC (2009). Cross enterprise

security and privacy authorization proﬁle for xacml

for healthcare.

OASIS XACML TC (2005). eXtensible Access Con-

trol Markup Language (XACML) version 2.0.

http://docs.oasis-open.org/xacml/2.0/XACML-2.0-

OS-NORMATIVE.zip.

The epSOS project (2007). An european ehealth project.

http://www.epsos.eu.

The IHE Initiative (2009). Basic Patient Privacy Consent.

http://www.ihe.net.

HEALTHINF2013-InternationalConferenceonHealthInformatics

268