Empowering citizens with access control mechanisms to their personal health resources

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 1 Title of the manuscript: Empowering citizens with access control mechanisms to their personal health resources Authors: J. Calvilloa,b, I. Romána,b, L.M. Roaa,b Affiliation: aUniversity of Seville, Spain, bCIBER de Bioingeniería, Biomateriales y Nanomedicina (CIBER-BBN) Corresponding author: Escuela Técnica Superior de Ingeniería, C. de los Descubrimientos, s/n 41092 Sevilla (Spain) Tel.: +34 954 485 976 E-mail address: [email protected] (J. Calvillo) Keywords: Distributed Systems, Patient Empowerment, Systems Integration, Semantics, Medical Informatics 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 2 Structured abstract: Background: Advancements in information and communication technologies have allowed the development of new approaches to the management and use of healthcare resources. Nowadays it is possible to address complex issues such as meaningful access to distributed data or communication and understanding among heterogeneous systems. As a consequence, the discussion focuses on the administration of the whole set of resources providing knowledge about a single subject of care (SoC). New trends make the SoC administrator and responsible for all these elements (related to his/her demographic data, health, well-being, social conditions, etc.) and s/he is granted the ability of controlling access to them by thirds parties. The subject of care exchanges his/her passive role without any decision capacity for an active one allowing to control who accesses what. Purpose: We study the necessary access control infrastructure to support this approach and develop mechanisms based on semantic tools to assist the subject of care with the specification of access control policies. This infrastructure is a building block of a wider scenario, the Person-Oriented Virtual Organization (POVO), aiming at integrating -related data. The POVO covers the wide range and heterogeneity of available healthcare resources (e.g., information sources, monitoring devices, or software simulation tools) and grants each SoC the access control to them. Methods: Several methodological issues are crucial for the design of the targeted infrastructure. The distributed system concept and focus is reviewed from the service oriented architecture (SOA) perspective. The main frameworks for the formalization of distributed system architectures (Reference Model - Open Distributed Processing, RM-ODP; and Model Driven Architecture, MDA) are introduced, as well as how the use of the Unified Modelling Language (UML) is standardized. The specification of access control policies and decision making mechanisms are essential keys for this approach and they are accomplished by using semantic technologies (i.e., ontologies, rule languages, and inference engines). Results: The results are mainly focused on the security and access control of the proposed scenario. An ontology has been designed and developed for the POVO covering the terminology of the scenario and easing the automation of administration tasks. Over that ontology, an access control mechanism based on rule languages allows specifying access control policies, and an inference engine performs the decision 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 3 making process automatically. The usability of solutions to ease administration tasks to the SoC is improved by the Me-As-An-Admin (M3A) application. This guides the SoC through the specification of personal access control policies to his/her distributed resources by using semantic technologies (e.g., metamodeling, model-to-text transformations, etc.). All results are developed as services and included in an architecture in accordance with standards and principles of openness and interoperability. Conclusions: Current technology can bring health, social and well-being care actually centered on citizens, and granting each person the management of his/her health information. However, the application of technology without adopting methodologies or normalized guidelines will reduce the interoperability of solutions developed, failing in the development of advanced services and improved scenarios for health delivery. Standards and reference architectures can be cornerstones for future-proof and powerful developments. Finally, not only technology must be follow citizen-centric approaches, but also the gaps needing legislative efforts that support these new paradigms of healthcare delivery must be identified and addressed. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 4 Body of the manuscript: I. INTRODUCTION Nowadays it is widely accepted that the application of Information and Communication Technologies (ICT) in the healthcare environment leads to the improvement of care delivery, not only enhancing citizens -being and social care. Moreover, it increases quality of life and independence as well as reducing rising healthcare costs in an ageing society. Subject of Care (SoC) centric approaches promote a personalized healthcare paradigm and represent a promising step forward. This paradigm could increase the involvement of the SoC in his/her own healthcare by encouraging him/her to take an active role in the management and maintenance of his/her health (e.g., by expressing concerns and preferences, participating in medical decision making [1], reinforcing the importance of lifelong learning and self-management, etc). A requirement for an efficient personalized healthcare scenario is the integration of all the available knowledge about each SoC into a cohesive whole [2]. Most efforts focused on the promotion of the SoC as a proactive agent in his/her own healthcare are refered to the term patient empowerment . This topic covers a wide spectrum of approaches and solutions, but there is still a long road ahead. A hot point of discussion is about the ownership of the SoC information and about who can decide policies to access it. National health laws [3], European directives and international recommendations [4-7] support that each individual must be able to control the information and resources related to him/her by avoiding unauthorized access. The trend is to involve the SoC not only in the maintenance of his/her health (through the awareness of all his/her information and resources) but also in the management and access control to them by means of the establishment of criteria that he/she considers adequate. This management paradigm of health resources (i.e., where the SoC is the absolute administrator and systems must ensure obedience to his/her preferences) is not easily achieved over currently deployed systems. If distribution and integration issues are considered, the accomplishment is even more difficult. Several initiatives trying to bring the management of health resources to the individual the information of which they handle can be found [8-10]. One of the most relevant of these is the Personal Health Record (PHR) [11], indicated as an electronic application through which individuals can access to and manage 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 5 their health information. Moreover, they can also share it with the person they authorize in a confidential, private and secure way. There are other examples such as the Person Controlled Health Record (PCHR) [10] or smart-cards scenario [12], where the information is carried by the SoC in a physical device and its disclosure is only up to the citizen. Most of these examples focus on centralized scenarios where resources belong to a unique administrative domain, but this assumption is far from reality. Healthcare scenarios with distributed resources are not a futuristic approach. Nowadays any SoC has resources (information, dedicated devices, etc.) related to him/her within different health organizations across separate regions and even countries. A real SoC- centric approach should be seamless to the geographical and administrative locations of resources and spanned over any domain holding resources related to the SoC. Obviously this scenario complicates access management tasks, hence more sophisticated procedures of security administration are required. Technology can ease the deployment of such paradigms and satisfy requirements of heterogeneity, distribution, and management by the SoC. Developers must not forget that if citizens have to design their own access policies, they must be provided with suitable tools. Therefore end-user applications have to be designed to ease their accessibility and use by the SoC, guiding him/her through understandable models and natural language and hiding the complexity of the computational languages for rule definition. Usability has been identified as a major asset to transfer the results of security and privacy research to practice in real systems. In this paper we introduce an open architecture following the principles of interoperability and system integration by using service-oriented architecture (SOA) [13] concepts and related standards. The proposed architecture supports a concept based on Virtual Organizations (VO) [14] that we have called Person-Oriented Virtual Organization (POVO). This concept emphasizes the definition of a VO, the objective of which is the health maintenance of an SoC who, furthermore, will also be the administrator. The POVO is a complex environment that involves many issues, and in this paper we address the access control management guaranteeing an essential security block. We stress the mechanisms of access control policy specification allowing the SoC to manage access to his/her health resources in a user-friendly and flexible way and deep granularity. The access control infrastructure shown in this paper is based on two essential points differentiating it from other studies. Firstly, it is completely oriented to be part of a standardized Healthcare Services Architecture following the SOA paradigm (Healthcare SOA, HSOA). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 6 To achieve this, the requirements of standards and methods for design and development (conforming to security standards [15-21], formalization in viewpoints [22-24], etc.) are taken into account. The second point relates to the usability of solutions to ease the administration tasks to the SoC. For this specific purpose, we introduce the Me-As-An-Admin (M3A) application, which guides the SoC through the specification of personal access policies to his/her distributed resources by using semantic technologies. I.1. The Person-Oriented Virtual Organization Paradigm At a high level, the SoC-centric paradigm covers a set of resources (human, administrative, computational, and informational) belonging to different administrative/technological domains, which are often geographically separated. In addition, resources are subject to sharing rules defined by an administrator who, in this case, is the very SoC to whom resources refer. This definition shares some features with the VO concept originally developed within the business domain and later adopted by the distributed system architectures [25-26]. By definition, a VO is formed in order to accomplish an objective common to all the stakeholders. In the healthcare domain, this objective would be the health, well-being and social care of a particular SoC (who is the administrator of the VO). To emphasize this orientation toward an SoC, we propose a new concept focused specifically on this domain: the personoriented virtual organization (POVO). Both the VO and POVO integrate heterogeneous systems distributed across administrative boundaries, and the different spanned domains must define cooperation links between them. An important divergence between these approaches is that the security in a VO is shared among the administrators of the involved domains. On the contrary, in a POVO, the correspondent citizen is the exclusive administrator of the resources and he/she can decide over who has access to them. Furthermore, while a VO is dynamically created to complete a business process, a POVO is strongly linked to the healthcare process performed during a particular person . Thereby, a unique POVO is created for each individual, evolves when his/her desires change, and is only destroyed when his/her life comes to end. emphasize that the POVO scenario centers on SoCs who are not only patients in treatment or monitoring but also any healthy individual involved in prevention tasks following the continuity of the healthcare model. Thus, healthy citizens can, for example, manage resources promoting their healthy life habits (meal ingestions, 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 7 exercises performed, etc.), maintain their well-being, prevent against diseases which they are prone to for genetic disposition, and so on. The complex model approached behind the POVO concept entails new requirements and scenarios to study. Since this paper focuses on the access control mechanism as an essential building block of POVO, we identify the requirements specific for this issue (instead of those for the whole POVO scenario): The POVO paradigm is SoC-centered, thus there shall be a unique POVO instance for each SoC. This instance shall cover all the resources related to the SoC during his/her entire life without the need for managing (i.e., creating/destroying) multiple instances. Nevertheless, an instance shall evolve anytime to meet The SoC is the owner of all the information related to his/her health and he/she must have absolute authority over access to that information within his/her POVO. Besides, the SoC must only be able to control access to the resources available in his/her POVO when those resources use information about him/her (see next point). Since resources shall be deployed and maintained by healthcare organizations or third parties, they will be subject to access (and use) policies defined by their legitimate owners. If resources use information related to the SoC (e.g., a computational model from an insurance company that is fed with health data), these policies cannot interfere with those specified by the SoC to control the access to the resources within his/her POVO (i.e., involving information related to his/her health). Access control policies must be as flexible as possible and allow different granularity levels covering the broadest range of the The SoC must be able to create, modify, and delete his/her access control policies. Both the management interface and the involved terminologies must ease the interaction of the end-user and promote usability. Administration tasks must be as seamless as possible in order to 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 8 allow the SoC to exploit the management capabilities of his/her POVO without need for advanced knowledge. There must be mechanisms of delegation of management privileges in order to cover scenarios where an SoC has no desire to manage his/her resources. Moreover, these mechanisms must be flexible enough to support the administration by parents or legal guardians in case of infants or disabled people. his/her resources can be temporally invalidated [3-7]. Therefore, accessing a resource without the SoC consent and violating existing policies must be possible if, for example, a health hazard or an emergency exist, with which delays can result in irreversible injuries or death risk. There must be auditing mechanisms to allow the recording of activities by users in a chronological order. All the information about access attempts (either successful or not), use, or modification of resources must be recorded. The supporting access control infrastructure for the POVO has been designed according to these access control requirements. The access control infrastructure is the first building block of the POVO which is composed of a wide spectrum of services. Looking at the big picture, a personalized and comprehensive health, social and well-being care could be supported by the combination of heterogeneous useful services. Value added services can be created in an easier manner, by combining previously existing capabilities, only if services are provided by systems designed by considering reuse and scalability. In this sense, we are designing an HSOA in which we combine and extend international standards for healthcare information services architectures [23] and others for specific fields such as security [15-21][27]. Details of the infrastructure and HSOA have been developed in a previous paper [28] and here we focus on issues of policy specification by the SoC. In the next section, the background of this paper is presented by identifying the main tools and technologies used. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 9 II. BACKGROUND II.1. Architectural Issues The POVO paradigm is supported by a healthcare architecture based on SOA and standards, improving interoperability, reuse of capabilities, and integration. An effective integration and composition of services supporting advanced capabilities can only be achieved through the deep understanding of the overall architecture. Furthermore, a precise formalization (e.g., based on modeling) of the healthcare architecture supports reasoning about the structural properties of the system and eases its evolution and the addition of new elements and services. A formal specification defines system components, or building blocks, their relationships and provides a plan from which products can be procured and systems developed. The suitable design and formalization of such an architecture must be done by using tools (i.e., frameworks, methods, and formal languages) from existing standardization efforts. Architectures adopting standards can aspire to acquire greater acceptance due to follow guidelines developed in consensus with Standard Development Organizations (SDOs). Different standards provide frameworks and reference models for the formalization of distributed system architectures. Two examples are the Reference Model - Open Distributed Processing (RM-ODP) [22] and the Model Driven Architecture (MDA) [29]. Although these standards differ in many aspects (e.g., viewpoints in ODP against a model approach in MDA), they do have a similar philosophy. They separate specifications targeting a technology-neutral viewpoint of the system (Platform Independent Model, PIM) from those including details that specify how a particular underlying technology is used in the system (Platform Specific Model, PSM). Since a particular PIM can be translated to different technological platforms, this approach improves the interoperability between components designed by following the same PIM even though they may have been developed using different technologies. Furthermore, this principle also facilitates the evolution of system components supporting the lifecycle and the migration of hardware and/or software and allowing the reuse of assets. The RM-ODP has been chosen for the standardization of healthcare services architectures in the European standard EN12967 (Health Informatics Services Architecture, HISA) [23] accepted as an ISO (International Organization for Standardization) standard in 2009. It is pointed out that the ISO/EN 12967 does not aim to represent a final complete set of specifications. On the contrary, it only formalizes 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 16 Fig. 2. Model from the Information Viewpoint integrating HISA with access control objects Moreover, the integration of the HISA Computational Viewpoint (third part of [23]) with the POVO objects is performed by establishing one computational object for each information object related to security. In order to include computational objects of access control, the requirements of the HISA Computational Viewpoint must be taken into account. The systems involved in the access control processes are defined here as computational objects and their methods are grouped in interfaces. In this viewpoint, standards such as XACML and SAML are very useful as a common ground for establishing protocols and interfaces. A potential risk in this point is to not separate completely the applied recommendations (e.g., XACML) from specific technologies (e.g., XML) which must be specified in the Engineering and Technology Viewpoints, but not here. Finally, it must be emphasized that the components supporting the access control in our approach have all been designed as services inside the HSOA, by using X.906 for their inclusion and formalization in the different ODP viewpoints, improving their reutilization and scalability. III.2. Translating the Preferences of the SoC to Machine-Processable Rules An essential requirement to make the management by any SoC of his/her POVO feasible is to emphasize the importance of usability and transparency of low-level details. Among the administration tasks, the SoC must be able to define access policies in different granularity levels. An example of a coarse-grain 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 17 to allow the access to the resources of my POVO to any hand, a fine- to allow my partner to see all my information related to sexually Our approach to translate these preferences (i.e., access control policies) to machine-processable rules is illustrated in Figure 3 and detailed below. According to [15], the PIP and the Policy Administration Point (PAP) perform tasks of policy provision and administration, respectively. The PDP makes decisions, and the Policy Enforcement Point (PEP) intercepts accesses. The Context Handler and other elements have been excluded for sake of clarity (a view of the complete architecture is detailed in [15] or [41]). Fig. 3. Relations between the elements of policy edition and access control decision making A. POVO Ontology and Metamodel To achieve the degree of flexibility required by access control policies, an ontology has been modeled for the POVO fulfilling all the potential features of resource categorization in the healthcare domain. By using this ontology, the SoC can have a versatile control over the access to his/her resources through: the potential actors who can access them, the nature of the information or the diseases related to him/her, creation dates, authors, physical location of access, etc. The developed ontology first appeared in [28] but it was described only briefly. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 18 This ontology covers basic concepts in a POVO and is composed of three parts: an ontology of healthcare actors, another focused on resource descriptors, and a third describing security issues to create access control policies. We have used the terminology of the European standard EN13940 [53] as the basis for the definition of numerous concepts and we have considered others with the purpose of meeting the great variability that currently exists. In addition, a multilingual labeling of concepts through RDF capabilities has been performed allowing non-English speakers to use the ontology. The ontology of healthcare actors identifies three main groups: people, organizations, and healthcare devices. The people group includes real individuals ranging from the SoCs themselves and healthcare professionals (physicians, nurses...) to relatives, friends, and caregivers. A potential attribute for describing individuals identifies their relationships with the SoC and this feature, among others, is used to feed the access control mechanism. The SoC will also be able to create new relationships fitting his/her needs. The second group of actors is related to organizations institutions that may play a role in the healthcare delivery process of the SoC (e.g., those involved in the maintenance of health and well-being such as gyms or dietary centers, insurance companies, laboratories or independent research groups, entities that deploy and maintain healthcare resources, etc). Finally, the third group includes the healthcare devices that have an important role in the healthcare environment as sources or sinks of information. They even sometimes work on behalf of real people, either healthcare professionals or the SoC. Two groups of objects to which access must be controlled have been considered: information and other resources. Both groups have attributes to be identified as well as control of versions and auditing. Information is structured into elements covering all the features related to health such as results of diagnostic tests, medications, exercise routines, eating habits, genomic information, etc. Resources (e.g., databases, simulation and modeling software tools...) are deployed and maintained by organizations and manage pieces of information about the SoC. Both information and resources will be categorized by using descriptors that allow pointing their nature (e.g., demographic, healthy lifestyle, eating habits, diseases, etc.) and indicating whether they are anonymized or not. Besides this classification (that can be done more or less automated), we have included other descriptors to ease the access policy creation. Thus, an SoC can, for instance: determine 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 19 which information is available for navigation and which is exclusively for his/her assistance; establish a control schema based on confidentiality levels; indicate what drugs, diagnostics, and treatments belong to his/her past health record and have no impact on the present; and a wide range of possibilities. In addition to the described features of the ontology, others are introduced focused on the relationship of the SoC with organizations (contacts, meetings, events and periods of attendance, etc.), on the classification of activities considering who executes them (automated by devices or performed by caregivers, health professionals, or the SoC him/herself), and on the access policy formalization (discussed in the next section). It must finally be clarified that the developed ontology does not try to build a complete solution but only represents basic concepts of a POVO illustrating how the access control could be solved in the presented scenario. Nevertheless, it is a flexible and scalable solution that can, through mechanisms for importing and merging ontologies, be fed on other widely accepted initiatives (for example, [54][55]). A metamodel for the access control policy editor has been built from the POVO ontology. Due to the wide range of concepts that the ontology holds, and for simplicity, we have worked on a reduced version holding only the security ontology (essential for the access control policy editing) and the healthcare actor ontology. The metamodel has been created in Emfatic [56], a convenient textual syntax for Ecore, and Figure 4 shows the main concepts and relationships. This metamodel serves as a proof of concept for showing the usability of a solution oriented to SoCs. In a real scenario, it should be extended with the whole POVO ontology and related standards. In this simplified metamodel, we introduce some concepts from ISO 22600 (BasicPolicy, CompositePolicy, and so on) illustrating a starting point of the integration with this standard. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 20 Fig. 4. Simplified metamodel for the access control policy editor As is depicted in Figure 4, the main concept is BasicPolicy which contains Nodes and Links. Nodes are used for policy edition and include: Healthcare_Actor who requests the access, Resource being accessed, and Obligations and Conditions that limit and impose restrictions to the access. Each node may hold Attributes which are textual in this first version. The relation between an actor and a resource is established through Auth+ or Auth-, specifying whether the access is permitted or denied a priori (i.e., conditions will have to be satisfied for granting access). Moreover, a Priority relation between policies can determine a preference in the checking order. This simplified metamodel has allowed building the M3A editor by using EuGENia tools. B. Me-As-An-Admin (M3A) - A User-friendly Access Control Policy Editor for Empowered Citizens in Health Usability has been identified as a major asset to transfer the results of security and privacy research to practice in real systems. There has been limited research into how to make complex security and privacy functionality understandable to those who must use it. This condition is essential in the POVO paradigm because the administration is carried out by the SoC, who maybe unfamiliar with technology. Thus, M3A 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 21 is designed to support SoCs with a variety of skills. The policy definition is made by using models that will automatically be transformed to the machine-readable policy, i.e. as SWRL rules. Figure 5 shows a screenshot of the M3A editor. Fig. 5. M3A Policy Editor and two example policies The editor includes a palette with the elements defined in the metamodel, and the SoC only has to drag and drop them into the workspace. Figure 5 shows an example composed of two policies. The left policy specifies the coarse-grain rule of Section 3.2 (i.e., any healthcare professional can access any resource for reading and writing with no restrictions or conditions). The right one describes the fine-grain policy indicating that the -transmitted diseases (STDs) which has been created after 01/01/2000. A condition limits the partner from reading information identifying any other person than the SoC. Furthermore, it is obligated that the access must be registered in an event log if it is to become successful. In this example a priority exists between the coarse-grain and the fine-grain policies. The latter must always be satisfied in first instance, therefore even ere a healthcare professional, he/she could not read clinical information related to STD between the SoC and his/her former partner (even after year 2000). In order to evaluate the usability of the M3A editor, a first validation phase has been performed on users with and without technologically skills. The acceptance has been generally high from both groups, and the most valued feature has been the intuitive interface. The usage results have allowed defining several restrictions in order to reduce common mistakes that may lead to malfunction. Some of these restrictions are: a priority link cannot be established between a policy and itself, there may only be a relation between 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 22 an actor and a resource, policies cannot be unnamed, etc. These restrictions have been specified through the Epsilon Validation Language (EVL) [57], a language similar to the Object Constraint Language (OCL). The special contribution of this approach is to assist SoCs with various skills to manage the access control to his/her POVO resources, thus a further validation is in progress with a large group of individuals and questionnaires to evaluate their experiences. The results of that validation phase will be more valuable to enhance the editor usability. The last, but not least, point of the procedure consists of transformations from model to text. Transformation rules have been defined by using the M2T project tools which allows obtaining from the metamodel instances created by an SoC, a plain text file with the corresponding policies as SWRL rules. These policies are incorporated into the POVO knowledge base (Figure 3) for the subsequent query by the PDP. The rationale and description of the access control policies proposed in this paper are extensively described in the next section. C. Access Control Policies Access control policies are stored in the knowledge base as SWRL rules. In this approach, a policy is a - le in which the antecedent is composed of elements (actors, resources, attributes, whether the requested action is permitted or prohibited. The specification of the two examples shown in Section 3.2 (which illustrate policies of coarse and fine-grain) as SWRL rules is: actionPermitted(?p, ?i) who:Person(?per) ^ who:hasRelation(?per, who:SPOUSE) ^ what:Clinical_Information(?inf) ^ attr:Sexual_Organs(?dis) ^ isRelatedTo(?inf, ?dis) ^ attr:Subject_Of_Care(?soc) ^ isRelatedTo(?inf, ?soc) ^ what:creationTime(?inf, ?time) ^ temporal:notBefore(?time, "2000-1- actionPermitted(?per, ?inf) The interpretation of a rule like the previous one is: if conditions specified in the antecedent are true (i.e. there are OWL instances among actor/s and resource/s. Although these two examples are permissions, prohibitions follow the same schema The process of rule checking and properties creation will be realized by an inference engine as is explained below. Jess has been used in this technological resolution, but the approach is technology-independent and it could use any engine. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 23 Before that, we must clarify how different policy ownerships coexist in a POVO. Three entities are able of creating access control policies: the SoC who owns authority over his/her information and can define rules according to his/her wishes, providers of the resources involved in the POVO who control access to them but who cannot interfere with policies defined by the SoC over his/her information, and finally, regional and international legislative organizations specifying policies to apply in exceptional scenarios in which the authority can be avoided. The access control specifications imposed by these three groups must coexist, and incoherencies cannot appear since they would result in incorrect decisions being made. Our solution is based on the following points: The policies established by legislative organizations have the highest priority level. Thus, a decision made in accordance with a policy of this group automatically overturns any policy stated by the SoC or resource owners. Among the legislative policies we can find, for example: those permitting the SoC to access all his/her information, or those considering emergency scenarios (physical injuries or death to SoCs, notifiable diseases, or health hazards). Although this policy group will always be activated, it only rules exceptional cases. In the usual execution of the system, the authority will seldomly be overturned. In a common scenario with no emergencies (i.e., no legal policies triggered), the policies defined by the SoC are responsible for the access control. The examples shown above illustrate the kind of policies included in this group. The third group is composed of the policies established by resource owners. These can only regulate the access to resources and never to information about SoCs. Since in general the resources will manage information to perform their tasks, a policy ruling the access to a resource must take into account the policies defined by the SoC for the piece of information used. Thereby, it can happen that a user has access to a resource (because the policies of the corresponding owner permit it) but not to the information used by that resource (as this is what the SoC specifies). The opposite case is also possible, a user can have access to clinical information but not to the resource using it (e.g., applications for statistical reports). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 24 The decision making process performed by the PDP follows the schema shown in Figure 6. When a PDP receives all the required information, firstly it combines the POVO ontology with the SWRL rules corresponding to the legal group, and the inference engine executes the inference. The inferred axioms are incorporated into the ontology, and a query language (in this case, the Semantic Query-Enhanced Web Rule Language, SQWRL) access requester and the requested resource. If the legal policies have specified this property, then access and, if it exists, the requester is denied access. In case no decision being able to be made, the inference process is once more executed but now with all the rules, i.e. adding the policies defined by the SoC and those by the resource owners. Once again, two queries are created to verify the existence of the properties of permission and/or prohibition. In this point, the possible scenarios are: 1. There is a property of permission (or prohibition). Then the decision of access acceptance (denegation) is made. 2. Two or more policies defined by the SoC are incoherent, and the two properties (permission and prohibition) exist at the same time. In this case, the most conservative decision is made (i.e., denying the access). Fig. 6. Access control decision process based on rules within the POVO scenario 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 25 3. There is no policy ruling the requested access and, since language is based on what is known as the open world assumption (OWA) (explanation described in the next paragraph), no decision can be made. This scenario is solved by making the PDP deny the request. The reasoning process over OWL is based on the OWA establishing that if something does not exist, it cannot be supposed. This notably affects the decision making in the POVO because there will always be access attempts not covered by policies. According to the OWA, in these cases, it cannot be supposed that access is prohibited. Thus, previously it will have to make a decision to cover cases without policy. We will make the most conservative decision consisting in denying access to the attempts not covered by POVO policies. In addition, all attempts will be registered by following log and auditing principles. Uncommon scenarios will be argued in the next section. IV. DISCUSSION IV.1. Exceptional Scenarios of SoC Administration In the previous sections we have covered the access control features required by the POVO paradigm and considered the common functional scenarios of access control. Besides these, there are complex questions that must be analyzed and solved. They are discussed below, and the rationale of how technology could support them is also presented. Despite this, it is out of the scope of the present paper to give a particular solution to each one. The first scenario we must analyze is in that the SoC is an infant. In the general situation the mechanisms of delegation of administration rights allow, if the SoC desires or he/she is legally disabled, granting the privileges of his/her POVO management to another person or administrative entity. Since that moment, the delegate obtains the role of POVO administrator and is able to access the information and resources, and create, modify and delete policies as if he/she were the SoC. Nevertheless, the SoC maintains his/her rights and can continue using them. The case of infants poses higher complications because unlike the previous situation, it is not permanent. Now the scenario suffers an evolution. First the POVO management is performed by the parents or legal guardians, and the infant cannot access his/her information or resources. When the infant reaches legal age, he/she becomes responsible for the 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 32 [13] Erl T. SOA principles of service design. Prentice Hall; 2008. [14] Foster I, Kesselman C, Tuecke S. The anatomy of the grid: enabling scalable virtual organizations. Int J High Perform Comput Appl. 2001; 15(3):200-22. [15] ITU-T Rec. X.1142 | OASIS XACML v2.0 Core: eXtensible Access Control Markup Language Version 2.0. 2005. Available from: http://www.oasis-open.org/committees/xacml [16] Cantor S, Kemp J, Philpott R, Maler E. Assertions and protocols for the oasis security assertion markup language (SAML) v2.0. 2005. Available from: http://docs.oasisopen.org/security/saml/v2.0/saml-core-2.0-os.pdf [17] ISO/TS 22600-1, 2:2006 Health informatics -- Privilege management and access control; 2006. [18] OASIS. Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare Version 1.0. 2009. Available from: http://docs.oasisopen.org/security/xspa/v1.0/saml-xspa-1.0-os.pdf. [19] OASIS. Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare Version 1.0. 2009. Available from: http://docs.oasis-open.org/xacml/xspa/v1.0/xacmlxspa-1.0-os.pdf. [20] IHE. IHE IT-Infrastructure White Paper - Access Control; 2009. [21] HITSP. HITSP/SC108 - Access Control Service Collaboration, Version 1.1; 2010 [22] ITU-T. Rec. X.901 Information technology Open distributed processing Reference model: Overview; 1997. [23] ISO12967-1, 2, 3: Health informatics Service architecture; 2008. [24] ITU-T Rec. X.906 | ISO 19793: Information technology Open Distributed Processing - Use of UML for ODP system specifications; 2008 [25] Sinnott RO, Chadwick DW, Doherty T, Martin D, Stell A, Stewart G, et al. Advanced security for virtual organizations: The pros and cons of centralized vs decentralized security models. In: 8th IEEE International Symposium on Cluster Computing and the Grid. 2008; p. 106-13. [26] Kerschbaum F, Robinson P. Security architecture for virtual organizations of business web services. Journal of Systems Architecture. 2009;55(4):224-32. [27] Karp AH, Haury H, Davis HM. From ABAC to ZBAC: The evolution of access control models. HP Labs Technical Report; 2009. [28] Calvillo J, Roman I, Rivas S, Roa L. Privilege Management Infrastructure for Virtual Organizations in Healthcare Grids. IEEE Trans Inf Technol Biomed. 2011; 15(2):316-23. [29] OMG. Model-Driven Architecture. Available from: http://www.omg.org/mda/ [30] Ferraiolo D, Kuhn D. Role-based access control. In: Proceedings of the NIST-NSA National (USA) Computer Security Conference; 1992. p. 554-63. [31] Patel-Schneider P, Hayes P, Horrocks I. OWL web ontology language semantics and abstract syntax. 2004. Available from: http://www.w3.org/TR/owl-semantics/ [32] Horrocks I, Patel-Schneider P, Boley H, Tabet S, Grosof B, Dean M. SWRL: a semantic web rule language combining OWL and RuleML. 2004. Available from: http://www.w3.org/Submission/SWRL/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 33 [33] Finin T, Joshi A, Kagal L, Niu J, Sandhu R, Winsborough W, et al. ROWLBAC: Representing role based access control in OWL. In: Proceedings of the 13th Symposium on Access Control Models and Technologies; 2008. p. 73-82. [34] Knechtel M, Hladik J, Dau F. Using OWL DL reasoning to decide about authorization in RBAC. In: Proceedings of the OWLED 2008 Workshop on OWL: Experiences and Directions. 2008. [35] Trivellato D, Spiessens F, Zannone N, Etalle S. POLIPO: Policies & OntoLogies for Interoperability, Portability, and autonomy. In: Proc IEEE Computer Society. 2009. [36] Elahi N, Chowdhury M, Noll J. Semantic access control in web based communities. In: 3rd Int. Multi-conference on Computing in the Global Information Technology; 2008. p. 131-6. [37] Shen H. A semantic-aware attribute-based access control model for web services. Lect Notes Comput Sci. 2009; 5574:693-703. [38] Priebe T, Dobmeier W, Kamprath N. Supporting attribute-based access control with ontologies. In: Proceedings of the First International Conference on Availability, Reliability and Security (ARES); 2006. p. 465-72. [39] Muppavarapu V, Chung SM. Semantic-based access control for grid data resources in Open Grid Services Architecture - Data Access and Integration (OGSA-DAI). In: Proceedings - International Conference on Tools with Artificial Intelligence (ICTAI); 2008. p. 315-22. [40] Amini M, Jalili R. Multi-level authorisation model and framework for distributed semantic-aware environments. IET Information Security. 2010; 4(4):301-21. [41] Blobel B. Ontology driven health information systems architectures enable pHealth for empowered patients. Int J Med Inform. 2011; 80(2):e17-e25. [42] Eclipse: Eclipse Modeling Framework (EMF). Available from: http://www.eclipse.org/emf/ [43] Amyot D, Farah H, Roy JF. Evaluation of development tools for domain-specific modeling languages. Lect Notes Comput Sci. 2006; 4320 LNCS:183-97. [44] Eclipse: Graphical Modeling Framework (GMF). Available from: http://www.eclipse.org/gmf/ [45] Kolovos DS, Rose LM, Paige RF, Polack FAC. Raising the level of abstraction in the development of GMF-based graphical model editors. In: Proceedings - International Conference on Software Engineering. 2009. p. 13-9. [46] MOFScript. Available from: http://www.eclipse.org/gmt/mofscript/ [47] Model-to-Text (M2T) project. Available from: http://www.eclipse.org/modeling/m2t/ [48] Kou S, Babar MA, Sangroya A. Modeling security for service oriented applications. In: ACM International Conference Proceeding Series. 2010. p. 294-301. [49] Mouelhi T, Fleurey F, Baudry B. A generic metamodel for security policies mutation. In: IEEE International Conference on Software Testing Verification and Validation Workshop (ICSTW'08). 2008. p. 278-86. [50] Karat J, Karat CM, Brodie C, Feng J. Privacy in information technology: Designing to enable privacy policy management in organizations. Int J Hum Comput Stud. 2005; 63(1-2):153-74 [51] Jess rule engine. Available from: http://www.jessrules.com/jess/index.shtml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 34 [52] Knublauch H, Fergerson R, Noy N, Musen M. The Protégé OWL Plugin: an open development environment for semantic web applications. In: Third international semantic web conference; 2004. [53] CEN/TC 251. EN 13940-1: Health informatics System of concepts to support continuity of care Part 1: Basic Concepts. European Committee for Standardization; 2006. [54] The Systematized Nomenclature of Medicine (SNOMED). Available from: http://www.ihtsdo.org/ snomed-ct/ [55] . Available from: http://www.obofoundry.org/ [56] Emfatic Language Reference. Available from: http://www.eclipse.org/gmt/epsilon/doc/ articles/emfatic/ [57] Epsilon Validation Language (EVL). Available from: http://www.eclipse.org/gmt/epsilon/doc/evl/