Federation and Security Aspects for the Management of the EHR in Italy

Abstract

The Electronic Health Record (EHR) or Electronic Patient Record is a collection of electronic health information about a patient, created to increase personal safety through more accurate evidence-based decision support. Healthcare organizations, especially in different regions/local governments, can have different architectural solutions and procedures, and thus different access control policies. The requirement of compliance with previously developed architectural solutions binds them to using a single Federated infrastructure model. Since data stored in the EHR Infrastructure concerns the health status of patients, they must be considered critical and their confidentiality and integrity must be protected by proper security support. In this paper we will present the analysis of federation and security aspects and issues for the management of the Electronic Health Record in Italy, suggesting a possible solution.

Full text

Federation and security aspects for the management of
the EHR in Italy
M.Claudia Buzzi
1
, Francesco Donini
1
, Abraham Gebrehiwot
1
, Alessio Lunardelli
1
,
Cristian Lucchesi
1
, Paolo Mori
1
1
CNR-IIT, Pisa, Italy
{Claudia.Buzzi, Francesco.Donini, Abraham.Gebrehiwot,
Alessio.Lunardelli, Cristian.Lucchesi, Paolo.Mori}@iit.cnr.it
Abstract. The Electronic Health Record (EHR) or Electronic Patient Record is
a collection of electronic health information about a patient, created to increase
personal safety through more accurate evidence-based decision support.
Healthcare organizations, especially in different regions/local governments, can
have different architectural solutions and procedures, and thus different access
control policies. The requirement of compliance with previously developed
architectural solutions binds them to using a single Federated infrastructure
model. Since data stored in the EHR Infrastructure concerns the health status of
patients, they must be considered critical and their confidentiality and integrity
must be protected by proper security support. In this paper we will present the
analysis of federation and security aspects and issues for the management of the
Electronic Health Record in Italy, suggesting a possible solution.
Keywords: eHealth, Electronic Health Record, SOA, federation, security
1. INTRODUCTION
The Electronic Health Record (EHR) is a collection of electronic health
information about a patient, created to increase personal safety through more accurate
evidence-based decision support. It may be composed of laboratory test results,
radiology images, vital signs, personal stats such as age and weight, and other
information that can be distributed to different Health Care Organizations (HCOs).
Some healthcare agencies also provide a patient summary containing all relevant
information such as blood group, allergies, vital medicines and others; the patient
summary is very useful in emergencies or to describe the general health conditions of
a patient. Different health care organizations may follow different procedures, and
thus direct various access control policies [1]. To facilitate the creation of the
Electronic Health Record by reassembling data maintained in different health care
organizations, the Italian Ministry for the Public Administration and Innovation is
supporting the process of building an interoperability framework for EHR
management; this framework will allow all citizens and authorized health
professionals to access the EHR wherever they are located. The health information
will be available for primary uses such as emergency assistance or evidence-based

2
decision support, but also for epidemiological studies, administrative purposes and
government. There are many requirements for the technological infrastructure of the
interoperability framework: it should be compliant with the architectural solutions
previously developed by the different regions/local governments; this requirement
binds to use a single federated infrastructure model. The technological infrastructure
needs to be consistent with Italian law regarding the Public Connectivity System
(SPC), which specifically regulates the rules for the Public Administration
communication. Furthermore, since data stored in the EHR Infrastructure concern the
health status of patients, they must be considered critical and their confidentiality and
integrity must be protected by proper security support; thus, access control in EHR
systems poses many challenges: the information is sensitive and highly confidential
but it may be necessary to access it (for instance, in emergencies) [1]. Moreover,
Italian guidelines for privacy in managing electronic health records [2] are based on
patient consent: each patient can choose his/her access control policies, e.g.: if the
EHR should be created and for how long, who if anyone may access a specific
document of the EH records, and the time interval when he/she can have access.
In this paper we will describe the analysis of federation and security aspects for
managing the infrastructure for Electronic Health Records in Italy, suggesting a
possible solution. The paper is organized into seven parts. Section 2 presents related
work, Section 3 briefly illustrates the interoperability framework of the Italian Public
Connectivity System (SPC) and Section 4 presents an interoperability framework for
Electronic Health Record (EHR) systems proposed in the OpenInFSE
1
2. RELATED WORK
project.
Section 5 introduces a short discussion on federated identity management aspects and
issues, also proposing a possible solution. Section 6 briefly describes security issues
and the management of the security policy. Section 7 ends the paper with conclusions.
Creation and management of the Electronic Health Record (EHR) is widely
discussed in the literature, but to the best of our knowledge few papers are specifically
related on infrastructure aspects. In 2006 Eyers et al. proposed a prototype for secure,
scalable, access control infrastructure for management of the EHR in United
Kingdom. The system was based on an OASIS open architecture for secure
interworking services, using the CASSANDRA language to express role-based access
control policies with the distributed model PERMIS. Our proposal is similar but we
use XACML (eXtensible Access Control Markup Language, [3]) for access control
policies [1]. Bergmann et al. presented a survey of architectural approaches for EHR
architecture, proposing a model for a virtual shared EHR that combines a patient-
centered integration policy with provider-oriented document management and
developing a system prototype [4]. A dated paper (2002) discusses priorities and
trends in development of the EHR infrastructure, describing the implementation of the
infrastructure for the regional health information network of Crete, Greece [5].
1
http://ehealth.icar.cnr.it

Federation and security aspects for the management of the EHR in Italy 3
Data protection is a main concern in the adoption of EHR in a real scenario.
Several studies have been performed to determine the security of the solutions
adopted to implement EHR in several countries. As an example, in 1995 the British
Medical Association (BMA), asked R.J. Anderson to analyze the main threats to the
system developed by the UK National Health Service (NHS) to manage personal
health information. In [6, 7], he reported some issues in the NHS threat model,
security policy and architecture, and he defined a new security policy model by
“translating the traditional ethics of the profession into a concise set of rules that
would provide a clear and unambiguous basis of communication between patients,
clinicians and policy makers on the one hand, and computer system builders on the
other”. In 2005, K.T. Win [8] investigates whether current information security
technologies are adequate for protecting medical data. In particular, he compares the
security requirements defined by the legislations of the United States of America and
of Canada with the available technologies for information security, concluding that
there is still room for improvement. Also D. Acharya, in [9], presents an overview of
the security threats in pervasive healthcare applications, and analyzes some open
issues. Instead, B. Hewitt, in [10], investigates how the security features affect the use
of EHR and proposed a model that incorporates into a hybrid Technology Acceptance
Model a set of security measures including biometric authentication, Multiple Access
Systems, and Single Sign On systems, to explore whether these measures influence
the healthcare organization decision to use the Electronic Patient Record. Finally,
guaranteeing secure access to clinical information is the main issue of [11], where the
authors formally specify access control policies in clinical information systems by
means of temporal linear first-order logic.
3. THE ITALIAN INTEROPERABILITY FRAMEWORK
The legal framework for the Italian e-Government strategy is the Code of Digital
Administration (CAD) which regulates the creation, management, preservation and
transmission of electronic documents used by the Public Administration and promotes
the reutilization of public information systems. The Code also introduces the Public
Connectivity System (SPC), i.e., the connectivity infrastructure for Italian PAs, and
the Public Connection and Cooperation System (SPCoop), the infrastructure for the
interoperability and cooperation between Public Administrations. The SPCoop model
is that of a “light SOA” based on three pillars:
• formalization of service agreements, which makes it possible to define
interfaces, behaviors, service level agreements (SLA), security requirements
and links with domain ontologies
• definition of a federated identity and its access management system
• definition of metadata, semantics and domain ontologies.
The SPCoop cooperation model is realized through the supply and use of
application services, that are offered by a PA through a unique (logic) element
belonging to its own information system, called Domain Gateway. In this way the
complete autonomy of the administration is guaranteed, as far as the implementation
and management of the provided application services, since they can be based on any

4
application platform supplied through the Domain Gateway (which handles the
routing of the application requests of a node -- administration or structure -- towards
the SPCoop infrastructure). The fruition of the application services is carried out
through the exchange of messages, whose format is formally specified in the Italian
standard referred to as e-Gov Envelope. Such a standard is basically an extension of
SOAP and represents the data structure used for the interactions between the domains,
also ensuring all the principles of security.
Fig. 1. SPC high-level architecture (© CNIPA
2
The ICAR
)
3
4. OPENINFSE INTEROPERABILITY FRAMEWORK
project is an Italian e-Government initiative that addresses the
establishment of SPCoop infrastructure for central and local governments. The ICAR
initiative (ICAR stands for “Infrastructure for Application services Cooperation
among Italian Regional authorities”) is setting up and testing the shared technical
infrastructure for delivering interoperability (IO) and applications cooperation (AC)
services among Italian regional authorities, following the national standards defined
for the development of SPC. Since in Italy the management of electronic identities
and security policies is left/delegated to the Regions, the ICAR initiative is trying to
implement an interregional Federated Authentication System.
The OpenInFSE project aims to implement an operational infrastructure to support
interoperability for the management and the recomposition of electronic health
2
http://archivio.cnipa.gov.it/HTML/docs/SPCoop-Introduzione%20ai%20Servizi%20SICA%2
0V_1.0.pdf
3
www.progettoicar.it/

Federation and security aspects for the management of the EHR in Italy 5
records (EHR): indeed, medical documents relating to the same patient could be
stored in different Italian health care organizations and each organization could have
different architectural and organizational systems. The infrastructure of the EHR must
operate at a national level and allow the localization and propagation of health
information scattered in the territory, by integrating all healthcare organizations
involved in the production or consultation of events related to a patient.
The logic interaction between HCOs is made with infrastructure components
developed ad hoc and localized in the Regions and the HCOs (all or just one for
administrative district), depending by the Region interoperability policies. The
architectural model of the EHR, based on decentralized and distributed architecture, is
then composed by first-level nodes (Regional nodes) and second-level nodes (local
nodes, the HCOs: hospital, laboratory test agency, pharmacies, etc.). At least each
first-level node should be connected to the EHR infrastructure through a Domain
Gateway, in order to allow SPC-compliant inter-regional communications.
The EHR model is SOA (Service Oriented Architecture) based on three levels:
1. Connectivity Layer: the Public Connectivity System (SPC) used for cooperation
among administrations through the exchange of "eGov Envelope"
2. Component Layer: specific infrastructure components developed ad hoc for
EHR infrastructure
3. Business Layer: services to support medical processes, such as “ePrescription”.
Services can be identified as part of the actors participating in the information
process.
The Components layer extends partly the SPC architecture; the components
proposed by the OpenInFSE for this infrastructure are:
Access Interface (AI): present in each node (regional or local). The AI represents the
access point of the infrastructure and receives all the requests made by regional actors
(e.g., health care professionals or paraprofessionals, administrative staff, but also
patients, who can access their EHRs) or by an AI of other regions. The AI interacts
with other infrastructure components to fulfill the request by notifying the event to the
broker nodes and the registers.
Document Manager (DM): stores documents associated with health events in a
persistent, reliable and secure way. Each node of the infrastructure, local and regional,
can interact with one or more repositories through one or more components of the
Document Manager. The Document Manager is able to process medical documents
structured according to the standard HL7 CDA Rel-2.0, but could be also compatible
with other formats of documents.
Federated Index Registry (FIR): acts as an index of documents and index of
services. It is an index of documents because it stores information (metadata) related
to medical records present in the repositories in order to facilitate searching and
localization. Moreover, it is an index of services because it stores service addresses
represented by metadata (e.g., URIs) enabling the location of the services that expose
local nodes. Registered members of the federation are aligned with each other through
a notification mechanism based on publish/subscribe paradigm events in order to
manage the redundancy of metadata.

6
Fig. 2. EHR architectural model
Hierarchical Event Manager (HEM): manages routing and notification of health
events to all stakeholders. To make management and event notification more efficient,
a hierarchical model for classification of events using of a publish/subscribe model
based on a broker is used.
Security Manager (SM): implements the security support of the EHR framework.
Since data stored by the EHR infrastructure are critical, proper security support is
required to protect them. The Security Manager is based on the security as a service
model (commonly in object oriented architectures), and it controls the Federated
Authentication and the Authorization process. The SM is indicated and is a unique
component but it includes some other components that will be described in the
following.
Fig. 3. OpenInFSE layers

Federation and security aspects for the management of the EHR in Italy 7
5. FEDERATED IDENTITY MANAGEMENT IN OPENINFSE
Identity management is a broad administrative area that deals with identifying
individuals in a network and controlling access to resources in that system by placing
restrictions on the established identities of the individuals. Federated identity
management is the means of linking a person's electronic identity and attributes,
stored across trusted multiple distinct identity management systems.
The OpenInFSE identity management architecture is compliant with the reference
implementation for Identity management released by the ICAR initiative (in the
following referred as ICAR INF-3); reuse of the reference implementations is one of
the requirements of the OpenInFSE project to better guarantee the integration with the
Regions infrastructures. At the moment, ICAR INF‐3 implementation supports only
the Web Single Sign On (Web SSO) profile, so compliance is possible only on this
profile. Instead, the federated identity management in OpenInFSE should use two
SAML profiles: Web SSO and also Web Services. In the following, we will describe
OpenInFSE requirements for the implementation of a federated identity management
model, based on the distinct existing identity management systems of the Italian
Regions. Furthermore, the interaction of the ICAR INF-3 components for the WEB
SSO profile and a solution to extend the Web Services profile for the ICAR INF‐3
reference implementation will be presented.
5.1. The OpenInFSE identity management constraints
Each Italian Region is responsible for the healthcare of citizens residing within
their region. In some cases, they have already implemented heterogeneous identity
management infrastructures. A requirement of the OpenInFSE project is to maintain
the already deployed infrastructures and to implement an interoperable federated
identity management system between the various regions using the SAML2 standard
protocol. The constraints are the following: 1. The identity of an individual is
managed by the Italian Region where a citizen/patient resides; 2. Individuals are
identified by an Identity Provider (IDP) using an authentication mechanism that is
decided by the Region; 3. An authenticated user is identified by various attributes
such as: first name, surname, date of birth, citizenship, sex, municipality of residence,
stature, eye color, etc.; 4. The role of the authenticated user is identified by various
Attribute Authorities (AA) using attributes such as: general practitioner, emergency
room doctor, patient, nurse, professional organization membership, administrative
employee of a hospital, pharmacist, etc.; 5. The electronic identity of an individual is
composed of the aggregate values of the identity and the role of the subject. The
aggregation is managed by an additional authority called the Profile Authority (PA).
The services offered by the Federation are distributed among the various Italian
Regions health care organizations using components called Service Providers (SP).
Access to services is managed through federated authentication and authorization
mechanisms. For federated identity access, the internal SPs within a particular region
appoint the Local Proxy (LP) to authenticate and retrieve the appropriate profile of a
user belonging to the Federation. The local proxy implements a Discovery Service

8
(DS) to locate the origin of the user Profile Authority. The interaction between the
common infrastructure components SP, IDP, AA, PA, LP and DS uses the SAML2
standard protocol.
5.2 Interaction of OpenInFSE components for the Web SSO profile
This part presents an example of interaction for the Web SSO profile. A Web
browser of a user coming from Region B tries to access a protected resource (an item
of the HCR) by a Service Provider (SP) in Region A using his federated identity.
Fig. 4. Interaction of OpenInFSE components for the Web SSO profile
The SP will redirect the web browser to a Local Proxy (LP) belonging to the same
Region. The SP does not have the knowledge of the complexity of the Italian
federated identity management system. It simply forwards every authentication and
attribute request to the LP. Subsequently, the LP forwards the authentication request
to the proper PA and the PA will also forward the request to the appropriate IDP: only
at this point, the user will be authenticated. Individuation/selection of both the PA and
the IDP generally require the interaction of the user. Once the user is authenticated the
Web browser containing the user’s identity will be redirected back to the SP. Details
of the interaction are described in Fig. 4.
5.3 Interaction of OpenInFSE components for the Web Services
The OpenInFSE Web Services infrastructure is implemented using the OASIS
Web Services Security (WS-Security) profile with the objective of providing
authentication, data integrity, and confidentiality of SOAP messages. The federated
identity management architecture for Web Services is shown in Fig. 5:

Federation and security aspects for the management of the EHR in Italy 9
Fig. 5. Typical Use of WS-Security with SAML Token [12]
Recovery of the SAML assertions containing the user profile is previously
obtained through Web SSO, as indicated in Fig. 5. The public key of the “sender” is
included as a SAML attribute in the assertion. Subsequently, the interaction between
the Front End and the Back End to protect the SOAP message is describe in the
following steps:
1. The “sender” constructs the SOAP message, including a SOAP header with a WS-
Security header. A SAML assertion is placed within a WS-Security token and
included in the security header. The key referred to by the SAML assertion is used
to construct a digital signature over data in the SOAP message body. Signature
information is also included in the security header.
2. The message receiver verifies the digital signature.
3. The information in the SAML assertion is used for purposes such as Access
Control and Audit logging.
6. AUTHORIZATION
Data protection is fundamental in infrastructure architecture for the management of
the EHR since stored data includes sensitive information that is highly confidential.
Obviously, health data are critical and must be properly protected. Metadata (i.e.,
pointers to health data/records) could also be considered critical, since they could
reveal that certain treatments or tests have been carried out on a patient, providing
indirect but clear information about his/her health status. Moreover, the need for an
advanced and flexible security support that provides an effective protection of the
patients’ data is also stated in the Italian guidelines for the EHR management [2]
issued by the Italian data protection authority.

10
The authorization is the decision process that determines the right of a given
subject to access one of the components of the EHR infrastructure to read or even
modify the stored data. The authorization process is performed after authentication, in
which the identity of the subject requesting the access has been verified, and the
SAML assertions representing the attributes the subject wishes to exploit in the
authorization process have been collected. The attributes collection is a very
important step, because the security policy will exploit those attributes to determine
the access rights. Hence, these assertions must be added to the access request
messages sent to the Component Layer services to enable the authorization process.
6.1 Role Based Access Control
The Role Based Access Control model (RBAC) [13] allows assigning roles to
subjects. In the EHR Infrastructure, the role represents the function of subject in the
healthcare system. As mentioned in Sec. 5.1, examples of roles are: general
practitioner, emergency room doctor, patient, administrative employee of a hospital,
pharmacist, etc. The RBAC model can be adopted in EHR management because it
allows defining access control policies where rights are paired to roles instead of
being assigned directly to subjects. Hence, an example of policy might be: data of a
patient (health and personal data) can be read by subjects who have the role
“Emergency Doctor”; a patient’s personal data can be read by subjects with the role
“Reservation Agent”; Health data of a patients can be modified by the subject who
wrote them.
6.2 Architecture
From an architectural point of view, the authorization process requires the
integration of some new components in the EHR Infrastructure defined for the
OpenInFSE project; the most relevant are the Policy Enforcement Points (PEP) and
the Policy Decision Point (PDP). The PEPs are in charge of intercepting the access
requests that are relevant from a security point of view, to trigger the authorization
decision process. An important feature of PEPs is that they must be non-bypassable,
i.e., they must be invoked every time that security-relevant actions are executed. PEPs
extract the assertions submitted by the user that represent his attributes from the
access requests, and embed them in the request for the PDP. PEPs invoke the PDP
and wait for the result of the decision process before performing the real access. If the
right is granted, the PEP resumes the execution of the access request, otherwise the
access request is deleted and the access is not executed.
A PEP must be embedded in each critical component of the OpenInFSE
Infrastructure. Hence PEPs will be embedded in the following Component Layer
services: Federated Index Registry, Hierarchical Event Manager, and Document
Manager, as shown in Fig. 6. The technique used for the integration depends on the
component’s implementation, that could be different in distinct Italian regions. Some
components could be already prepared for the integration of PEPs. As an example, the

Federation and security aspects for the management of the EHR in Italy 11
standard OASIS ebXML Registry 3.0 [14], that could be adopted for the
implementation of Federated Index Registry can be configured to invoke the PDP. If
the component is implemented as a web service, the PEP could be implemented
exploiting the Inflow Handler Chain. In this case, a new handler that invokes the PDP
is added to the original chain. This handler is invoked every time that a request
message is received, and if the PDP response does not allow the execution of the
request, the handler simply deletes the request message and returns an error to the
requestor. Another solution for integration of the PEP in components of the EHR
infrastructure is to develop a wrapper service that is invoked instead of the original
one. The wrapper service invokes the PDP, and then invokes the original service only
if the PDP response is positive.
Fig. 6. Integration of PEPs in the EHR architecture components
The PDP is the component of the architecture that performs the access decision
process to determine whether a given subject has the right to perform the access
he/she required. At first, the PDP obtains the security policy from a repository,
managed by the Policy Administration Point (PAP), and it builds its internal data
structures for the policy representation. Next, it receives the access requests from the
PEPs embedded in the EHR Infrastructure components. A PDP can be paired with
more than one PEP. Communication between the PEPs and the PDP can be performed
exploiting the SAML protocol [15], and should be secure to protect both the integrity
and the confidentiality of the requests and responses. Since the Security Manager is
implemented as a web service, the SOAP Message Security standard defined by the
OASIS consortium [16] can be adopted to secure the interactions between PEPs and
PDP. Before evaluating the security policy, the PDP checks the validity of the
attribute assertions received in the access request (e.g., the validity of the signature of
the issuer, and the expiration date). The security policy is expressed exploiting the
XACML language [3], which is a well-known and widely used standard that naturally
allows the use of roles in the authorization process [17]. The XACML language is
adequate for expressing the security policies required for protecting EHRs because it
allows to represent roles for subjects and to assign rights to roles, to exploit attributes
to perform the decision process, and it is flexible enough to express also specific
access restrictions required by the patients. The PDP could invoke a further
component of the architecture, the Policy Information Point (PIP), when the attributes
required to perform the decision process are not included in the set that has been
submitted by the requestor. Hence, the PIP is in charge of retrieving the fresh values
of the missing attributes. Some free implementation of the XACML PDP is currently

12
available, such as the one released by SUN
4
, that currently supports the XACML
version 2.0. Axiomatics
5
7. CONCLUSION
, instead, provides a commercial version of the XACML
framework that implements the full Policy Life Cycle Management for XACML
policies, from editing to enforcement.
This paper describes the infrastructure defined by the OpenInFSE project to
support interoperability between the various organizations operating in the Italian
healthcare scenario for the management and recomposition of Electronic Health
Records. There are many crucial requirements, among these the compliance with
previously developed local architectural solutions and with the Italian laws, the
distributed architecture, criticality and confidentiality of data managed. After a
general presentation of the project and the Italian Public Connection and Cooperation
System for managing communication between healthcare organizations, in this paper
we have focused on the adoption of a federated identity system and a proper security
support for preserving the confidentiality and the integrity of data stored in the
Electronic Health Records. Furthermore, the paper proposed a possible solution for
the implementation of federated authentication and authorization in the OpenInFSE
infrastructure, based on the ICAR INF3 project and the OASIS XACML standard for
the RBAC model. The next step of the OpenInFSE project will be the test of the
described components with three Italian Regions, in order to verify and tune the
architecture.
Acknowledgments. This work was supported by the joint project CNR-Presidenza
del Consiglio dei Ministri: Infrastruttura Operativa a Supporto dell'Interoperabilità
delle Soluzioni Territoriali di FSE nel Contesto SPC.
REFERENCES
1. D. M. Eyers, J. Bacon, and K. Moody. OASIS Role-based Access Control For Electronic
Health Records. In IEEE Proceedings on Software, 153(1), pp. 16-23. IEEE, Feb. 2006
2. The Italian Data Protection Authority, Linee guida in tema di Fascicolo Sanitario
Elettronico (FSE) e di dossier sanitario – 16 luglio 2009 (G.U. n. 178 del 3 agosto 2009)
3. OASIS, eXtensible Access Control Markup Language (XACML) v.3.0. 16 Apr 2009
4. Bergmann, J., Bott, O. J., Pretschner, D. P., Haux, R.: An e-consent-based shared EHR
system architecture for integrated healthcare networks, International Journal of Medical
Informatics, v.76, is. 2-3, pp. 130-136, ISSN 1386-5056, 10.1016/j.ijmedinf.2006.07.013.
http://www.sciencedirect.com/science/article/pii/S1386505606001973
5. Tsiknakis, M., Katehakis, D. G., Orphanoudakis, S. C.: An open, component-based
information infrastructure for integrated health information networks, Int.Journal of
4
http://sunxacml.sourceforge.net/
5
http://www.axiomatics.com/products.html

Federation and security aspects for the management of the EHR in Italy 13
Medical Informatics, v. 68, Issues 1-3, pp. 3-26:
http://www.sciencedirect.com/science/article/pii/S1386505602000606
6. Anderson, R. J.: A Security Policy Model for Clinical Information Systems, IEEE
Symposium on Security and Privacy, 1996, pp. 30-42
7. Anderson, R. J.: Security in Clinical Information Systems, Computer Laboratory
University of Cambridge, 1996
8. Win, K. T.: A review of security of electronic health records, Health Information
Management, 34(1), 2005, pp. 13-18
9. Acharya, D.: Security in Pervasive Health Care Networks: Current R&D and Future
Challenges, Mobile Data Management, 2010, pp. 305-306
10. Hewitt, B.: Exploring how security features affect the use of electronic health records,
Healthcare Technology and Management, 11(1/2), 2010, pp. 31-49
11. Sohr, K., Drouineaud, M., Ahn, G.: Formal specification of role-based security policies for
clinical information systems, SAC: Security Track, ACM, 2005, pp.332-339
12. Security Assertion Markup Language (SAML) V2.0 Technical Overview Committee Draft
02, 25 March 2008
13. Sandhu, R.S., Coyne, E. J., Feinstein, H. L., Youman, C. E.: Role-Based Access Control
Models, IEEE Computer, 29(2):38-47, Feb. 1996
14. OASIS, ebXML Registry Services and Protocols Version 3.0, OASIS, 2 May, 2005
15. OASIS, SAML 2.0 profile of XACML v2.0, OASIS Standard, 1 Feb 2005
16. OASIS: Web Service Security: SOAP Message Security 1.1 (WS-Security 2004) OASIS
Standard incorporating Approved Errata, 01 November 2006
17. OASIS, XACML Profile for Role Based Access Control (RBAC). 13 Feb 2004