{'fraction_non_alphanumeric': 0.02328304558575241, 'fraction_numerical': 0.003594575458853004, 'mean_word_length': 5.23374639280258, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Modeling and Recognizing Policy Conflicts with Resource Access Requests on Protected Health Information

This article discusses potential clashes between different types of security policies that regulate resource access requests on clinical patient data in hospitals by employees. Attribute-based Access Control (ABAC) is proposed as a proper means for such regulation. A proper representation of ABAC policies must include a handling of policy attributes among different policy types. In this article, we propose a semantic policy model with predefined policy conflict categories. A conformance verification function detects erroneous, clashing or mutually susceptible rules early during the policy planning phase. The model and conflicts are used in a conceptual application environment and evaluated in a technical experiment during an interoperability test event.


Introduction
Hospitals as crucial facilities of public health systems are categorized as critical infrastructure and are also constrained by additional regulation due to the sensitivity of the processed medical data. In acknowledging this strong correlation between safety and security, public administrations merged formerly separated safety and information security programs into consolidated guidelines that are considering information security as a fundamental corner stone of maintaining the availability, safety, and proper functioning of such critical infrastructure.
The information security of the processed data, applications, and health information technology (IT) systems is safeguarded through an information security management (ISM). Its defined objectives and controls assure a proper regulation of access to facilities that process information as well as the disclosure of protected (health) information [1].
The rules for any legitimate system access or information disclosure are documented in regulatory, compliance, and enterprise constraints, however, are usually not immediately machine processable. Access Control Systems (ACS) are utilized to formalize and combine any relevant constraints into commonly processable rulesets [2]. Attribute-based Access Control (ABAC) is one model capable of implementing a top-down-driven ISM in a hospital environment with the inherent advantage of explicitly concentrating on formalizing, combining, and processing access and disclosure regulation through sets of policies [3]. The latter contain legally binding rulesets, enterprise objectives, and general information security concerns in a formalized and processable technical representation. The eXtensible Access Control Markup Language (XACML) [4] perfectly fits to express fine-grained ABAC policies. Due to multiple attributes, context-sensitive access requests are more precise than, e.g. requests derived from the Role-based Access Control (RBAC) model which is quite common in hospital information systems.
In the ABAC model, a permission to a protected information object or resource is described with a number of subject, object, or environmental attributes. Each attribute is represented by key-value pairs and might be gathered at runtime to evaluate a dynamic authorization decision. During such evaluation a security context is created and anchors approvals to access an information object [5, p. 18]. In the RBAC model, the authorization decision to an object or a resource relies solely on an assigned role to a subject.
However, the syntactic and semantic correctness of all attributes must be ensured in both information security policies and access control policies. The multitude of simultaneously applied policies with varying degrees of abstraction and an increasing use of IT in a hospital lead to an ever-growing risk of individual policies conflicting with each other. Those collisions may paralyze the ACS ability to decide on the legitimacy on access requests and cause a denial of service situation or a confidentiality breach, effectively crippling the health IT ability to function and perform properly.
Therefore, assessing how policy conflicts can be identified and mitigated in order to prevent illegitimately assigned access rights or violating any data disclosure laws are being observed in this work. Previous approaches to policy conflict detection cannot be transferred easily to a hospital information system because their characteristics do not consider policies of different types. Usually, individual information systems are safeguarded locally with isolated access rules. There is a lack of visibility into the different types of policies for managing patient data access, which takes into account the information management of a hospital. For this reason, it is necessary to work out the relationships and characteristics of the different policy concepts (e.g. impacts on safeguards for health information through a patient consent and rules of the operational and organizational structure). This forms the basis for the analysis of policy realms.
This contribution presents a policy model and related specific conflict categories. Both are applied in a conceptual application environment and evaluated afterwards. By using above mentioned IT artifacts, clashes in and between access control policies, patient privacy policies, and information security policies can be recognized, effectively enabling a focused mitigation or ideally a correction. Therefore, the management of a hospital information system is supported on a tactical and operational levels.
The remainder of the article is structured as follows: Section 2 gives an overview of the research approach of the presented work. The Section 3 presents policies that control the resource access demands on patient data and discusses the related work. The Section 4 outlines a semantic policy model and introduces policy conflict categories. The Section 5 is concerned with the presentation of the policy management system which uses both the model and the conflict definitions. The Section 6 provides a discussion considering the evaluation of the developed model and conflicts and outlining implications for practice. Finally, a concluding section summarizes the key findings of this article.

Research Approach
The starting point for the investigation of the problem areas outlined in Section 1 is how policy-based information security management can be used to identify and deal with conflicts between rulesets in a computer-assisted manner. The derived research questions are: • Access context for protected health information: What are the mandatory rules for operational access to patient data in a hospital and which policy concepts represent these rules? The following overall research objectives intend to address the stated problems: • Legally binding regulations as well as internal and regulatory requirements must be combined in order to differentiate the policy concepts. The nationally applicable orientation guide for hospital information systems "Orientierungshilfe Krankenhausinformationssysteme" (OH-KIS) [6] of the German Working Group for Health, Social Affairs and Technology of the Federal and State Privacy Commissioners provides a significant foundation and relevant information for the mapping of data protection-compliant accesses to the hospital's service processes. This information must be used for the differentiation of the policy concepts. • In addition to the analysis of the dependencies of regulations and guidelines in a hospital, a semantic model for such policies is to be defined. • Based on the policy model, the conflicts between the policies are analyzed.
• Policy model and policy conflicts are to be integrated into an application concept in order to demonstrate the concrete implementability. A prototypical application underlines the evaluation of the application concept, including the policy model and policy conflicts.
The used research approach for our work is Design Science Research (DSR) [7] which aims to describe an information system problem closely, to develop iteratively a solution to the problem (expressed as built design or IT artifacts) and finally to evaluate it. According to the phase model of Peffers et al. [8] this DSR research approach can be outlined as follows (phases are indicated with italic): 1. The first phase starts with problem identification and motivation. The development of the IHE 1 white paper on access control in healthcare scenarios [2] revealed that the handling of policy conflicts of different types in distributed environments is very complex. The concrete contents of the different policy types are not elaborated in this white paper. Initial research questions could be derived from this and raised, among other things, the question of how violations of information security can be recognized by an investigation of policy conflicts.
Although the topic field (security) policy is extensively addressed in the literature, policy conflicts in the health IT environment are not considered in detail. The published state of the art is largely restricted to similar policies, such as network policies or authorization policies. The subject area policy conflicts in the health care system was limited to the hospital. A carried out case study confirms that operational access requests are not justified by information security policies [9]. 2. From these activities, requirements for the solution have been developed and possible design artifacts defined that addressed the problem adequately (cf. [10]). The research questions were refined and the objectives defined in the subsequent second phase. 3. After the definition of objectives, the actual process could start to develop the design artifacts (cf. [10], [11]). By separating the scope of tasks for policies, an exact analysis of potential conflicts in access requests to protected health data is achieved. Starting from established frameworks of information security, policy concepts were successively linked with further concepts into a policy model. This was done by incorporating amongst other things the policy concepts of the IHE white paper [2] and the orientation guide for hospital information systems [6]. Contributions to policy conflicts from the literature were applied to the policy model. Further specific policy conflicts (dedicated to the hospital scope) could be defined as well. 4. The policy model and the conflict definitions were integrated and transferred to an application concept. This demonstrates how these artifacts might be applied (cf. [3]). 5. The subsequent evaluation phase clarifies the extent to which the research objectives fit into the results of the evaluation. This article summarizes findings of previous work that is described in the phases before and presents also these results.

Characteristics of Resource Access Demands on Patient Data
This section deals with the description of the access context for protected health information and outlines our policy model that has been developed (cf. Section 4). In addition, it presents related work in security policy management in healthcare and conflict resolution techniques. The goal of a policy organization is to combine various policy concepts thus making them comparable and identifying clashes so that the policy concepts can ultimately be implemented. Policy concepts in healthcare environments include [2] • rules for protecting medical data from illicit disclosure (policy concept compliance), • patient's constraints given in a consent (policy concept patient consent), and • constraints derived from the intended use of a certain healthcare system (policy concept purpose of use).
A proper information security management (ISM) puts a stop to illegitimately disclosure of protected health information. Preferably, access demands derived from the policy concepts described above are directed at compatible security policies setup. It is to be noted that such policies must be implemented and enforced adequately and in context of their individual criticality. The Unified Modeling Language (UML) class diagram in Figure 1 depicts the placement of policy types to the information security management and illustrates the policy-based protection of health information: • The ISM starts with an Information Security Policy that holds general principles, fundamental objectives and responsibilities for the protection of any information being processed in an organization. • The Information Access Policy is the logical part that details the lawful access to any protected health information in accordance with terms of compliance and regulatory mandates of an organization. Access demands are managed by dedicated subsystems of the entire hospital information system (HIS).

Figure 1. Policy types involved for accessing protected health information
• A Resource Behavior Policy reflects the operational need or purpose of use. That is, certain subjects might act on certain resources which are to be processed by information systems, such assignments are an essential part of this type of a policy. • A Patient Privacy Policy is a fundamental prerequisite for giving permissions for processing health data of a patient. It is derived from the patient consent and yields potential access permits. • Viewed logically, a Resource Access Policy holds specific characteristics of authorizations to certain individuals and organizations in order to use relevant applications (e.g. Electronic Medical Record [EMR] system) to the extent of the agreed purpose-of-use in the given patient consent and organization of work of the facility. • Essentially, permissions are access rights that are assigned to subjects or roles in a discrete access context. Considering that, an additional Access Control Policy must be defined that holds these assignments. Access demands by hospital's employees intersect with potential permissions yielding the need-to-know realm.
In summary, all these types of policies presented in Figure 1 implement an Attribute-based Access Control (ABAC). As mentioned before, ABAC policies inject additional attributes from all relevant information systems such as subject, object or environment conditions into an authorization decision process. With that said, syntactic and semantic correctness of these attributes must be ensured in all policy types in order to justify and finally affect an authorization decision. We developed a proper policy representation approach and management of attribute values discussed in Section 4 that tackles the syntactic and semantic correctness of policy attributes. This handles potential interoperability issues among attributes in contrast to atomic values normally used in ABAC [3].

Related Work
A security policy class hierarchy was already modeled by the Health Level Seven (HL7) Security Work Group [12]. Different viewpoints detail business and engineering aspects in a domain analysis model dedicated for healthcare environments. From a security policy point of view, the domain analysis model is highly focusing on access control. Role-based Access Control (RBAC) [13] is considered as the access control paradigm of choice in this domain analysis model which is along with the previously mentioned orientation guide for hospital information systems [6]. RBAC states that authorization decisions on the access to certain objects rely on pre-defined roles which are assigned to subjects in user sessions. We, however, regard RBAC policies as not entirely suitable for representing actual workflows in hospitals and propose the ABAC model [3]. A top-town information security management as well as the identification of policy clashes are not addressed by the domain analysis model. However, we adopted the flavors of access control policies to our model (authorization policy, constraint policy, delegation policy, refrain policy, and obligation policy).
Our developed policy model is based on Semantic Web technologies. The policy languages Rei [14] and KAoS [15] use that approach as well. These languages are rather domain-independent and cope with authorization policies. We apply our policy model to the hospital's organization of work plus security and privacy rules. That is why our definitions of policy conflicts are more extensive and comprehensive. Policy clashes occur on different levels, not only with authorization policies.
Mouelhi et al. [16] introduce a Model-driven Engineering (MDE) process that transforms an access control policy into security components. These components can be integrated into executable program code and are actually the Policy Enforcement Point (PEP) as well as the Policy Decision Point (PDP). These two components regulate the authorization request and decision regardless of the business logic of a software application. An access control policy is specified in a generic meta model. With this meta model, RBAC policies can be described. A verification routine checks the conformity of the specific policy to the meta model as well as existing conflicting rules for permission, prohibition or obligation. The MDE process also provides for the generation of Java code, which generates XACML program code for a PEP as well as a PDP. This procedure provides only rudimentary checks on policy conflicts. It is only able to uncover contradictory permissions and obligations. Although the policy meta model is generic the support of other policy types such as a patient privacy policy is missing. Also, no statements are made about how policies can be related to each other to determine dependencies between different policy types [16].

Semantic Policy Model
In a previous work [17], we introduced a semantic policy model that expresses the policy concepts through the policy types from Section 3: We rely on ontologies as a means of a proper policy representation. An important advantage to this knowledge representation approach is the linking of knowledge with inference and constraints. These are rules for the preparation and logical reasoning of new contexts and links (and thus the derivation of new knowledge) as well as to ensure their validity.
The policy ontologies are engineered according to the frames concept [18]: Classes (class frames) stand for a lot of similar objects. These classes can be assigned properties and relations in the form of attribute sets (slots). With the help of further features (facets), slots can be filled and controlled with values (filler). Classes can be instantiated (instance frames) and represent individual concepts or objects of the class. Through the supported concept of specialization, Instance Frames inherit all the properties of Class Frames and can also include additional properties [19].
The fundamental design goal of the policy model is to use strictly externalized values of policy attributes since this at least simplifies the conflict handling if not preventing it altogether. As a modeling approach, the frame paradigm is used because the filler concept can be linked perfectly with terminology services.
The CTS2 -linked data edition (CTS2-LE) [20] is an implementation of the Common Terminology Services 2 (CTS2) [21] from the Object Management Group (OMG). The CTS2 specification simplifies the definition of identifiers and interrelations of terminology concepts via a standardized interface. Initially intended for representing medical code sets, CTS2 provides various means to represent arbitrary code sets and value sets. The CTS2-LE terminology service enables the definition of multiplicities as well as constraints on properties of resources of the Resource Description Framework (RDF) [22] via so-called RDF signatures. RDF and the RDF Schema [23] describe structural constraints according to the CTS2 information model. The underlying rule engine ensures that the frames paradigm is properly applied to the RDF signatures. Thus, instances of RDFS classes in RDF graphs (i.e. representation of terminology concepts) are in accordance with class frames and fillers.
We adopted the CTS2-LE implementation with the frames-oriented rule engine and enhanced it with RDF signatures of our policy types presented in Section 3. Each policy type is written with the RDF syntax "Turtle" and holds specific policy attribute types in a respective ontology (in total five). Inheritance structures of classes and multiplicities are used in the RDF signatures as well. Figure 2 shows a graphical representation of a sample policy rule from a Resource Access Policy. The policy statement "I hereby authorize physicians at Clinic A to use the 'Historical Database' application in order to access all my lab data for the purpose of medical treatment" consented by a patient can be linked with a terminology server ("controlled vocabulary" layer). Different layers organize a proper linkage of policy attributes with coded attributes that are managed by that server. The RDF signatures of our different policy types belong to the "policy schema" layer. A proper separation of policy types leads to cross-linked attribute definitions. The next layer "restriction policies" represents normative policies with RDF instances of the "policy schema" layer. These policies are in accordance with the organization of work and tasks which are to be expressed by means of a Resource Behavior Policy and an Information Access Policy. New policy instances are ranged in the last layer "policy instances".
In summary, Figure 2 reveals possible clashes of a Resource Access Policy with other policy types. Thus, Resource Behavior Policies and Information Access Policies also need to be in a suitable alignment with the above policy statement. Using this policy model and the proposed linkage with a terminology server, coded attributes in ABAC policies get more semantics. A proper attribute definition is important for both activation of a policy and decision on a policy.

Policy Conflict Categories
Given the policy model potential clashes between the policy types can be analyzed. Previous work on policy management shows that concise conflict categories are in place. We applied these categories on our policy model and defined further categories that indicate conflict ability. The following policy conflict categories are defined for the policy model: • Goal conflicts: Policy subjects, resources and actions can overlap. For instance, special constellations may lead to a conflict of duties, conflict of interests or self-management [24]. • Modality conflicts: Authorization policies contradict with each other when permissions are set in two ways: One assigned permission to a subject permits access to a resource whereas another one denies it. The same servers for obligations (i.e. actions that must be  Figure 2. Policy relationships on the basis of a terminology service executed in conjunction with an authorization or action that are refrained from execution) [24]. • Domain conflicts: This semantical conflict category treats with functional dependencies among policy attributes. Since coded attributes are used for describing a policy state, the codes might contradict when different policy types apply simultaneously. To tackle code relations, subsumption relationships can be defined so that CodedV alue P olicyT ypeA ⊑ CodedV alue P olicyT ypeB applies.
• Data conflicts: Data conflicts can be significantly mitigated or even avoided by using the CTS2 terminology service. Policy attributes with stored code systems or value sets can be linked with additional codes via the CTS2 Map Services to organize semantically same attributes. Thus, different identifiers (i.e. designators) and different scales of a code value are available. • In-congruent policy concerns: Erroneous rules may occur with respect to different policy concerns. For instance, if no patient consent is given to a particular resource access, physicians must be refrained from accessing the patient data. This requires that subjects, resources and actions must be in accordance with the rules from compliance and the defined purpose of use of dedicated information systems and applications.
• Special conflicts: Based on the policy types, specific policy conflicts can be defined. For instance, if a patient limits access to his or her data for the purpose of treatment in a Resource Access Policy, but this is not compatible with the existing processing purposes (and associated accesses to application systems) because no intended recipient of information from an Information Access Policy can ensure treatment under these conditions. Another policy clash might occur if the access to an application system is implemented correctly (amongst other things via an Information Access Policy) but no authorization is given. In this case a conflict between a Resource Behavior Policy and an Access Control Policy exists.

Recognizing Policy Conflicts
As a query language, the SPARQL Protocol and RDF Query Language (SPARQL) [25] is predestined for RDF support. Since the policy model is in RDF, queries about policy conflicts can also be formulated implementation independently with SPARQL in order to recognize them.
All defined policy conflicts can be identified using this approach. For instance, the following query recognizes a conflict of duty (i.e. an overlapping between subjects and objects among two policies). Other conflicts can be identified analogously:

Support for Relationships Among Coded Policy Attributes
A special handling of domain conflicts is required. Policy attributes (e.g. policy actions) can be distributed taxonomically across multiple policy types. This can cause inconsistencies if contradictory attribute values are used in policies. We define subsumption relationships between policy actions with a dedicated RDF signature: An instance of this RDF signature is given in Figure 3 which shows the graph structure in a UML-like notation (generalization is indicated with dashed lines whereas associations are shown with solid lines). The data activity "USE" is defined as a superior action of the access types "READ" and "EXECUTE" dedicated for describing accesses to healthcare information systems. The access type "READ" includes a specific access control action of a healthcare information system (in this case "RegistryStoredQuery"). Each attribute is used in different types of policies and linked with a terminology service.

Conceptual Application Environment
According to the DSR approach, a demonstration of the utility of the design artifacts "policy model" and "policy conflicts" is necessary. For this purpose, we introduce a Policy Management System (PMS). This system is the central database for policies and provides functions to detect policy conflicts (design artifact of the type "instantiation"). In addition, this system provides basic policy management tasks which include querying, as well as providing and storing policies. It is based on a standard policy vocabulary configured in a Common Terminology Service based on CTS2-LE.
The overview in Figure 4 shows how the individual logical components of the PMS are integrated into the hierarchical architecture design with the three layers (1) external interface (Web Service Endpoint), (2) application core (Modules), and (3) data management (RDF Store). The entire application logic is divided into the seven components, which have a common interface for the users of the Policy Repository Service: The services of the PMS are provided by means of the "SPARQL 1.1 Graph Store HTTP Protocol" [26] as well as the "SPARQL 1.1 Protocol" [27]. REST-based web services published via the Web Application Description Language (WADL) assure a consistent usage of all PMS services.

Policy Conflict Handling
It is the primary interest to work out an application concept with simple and effective treatment strategies. That is why we consider the static analysis of policy conflicts during policy design rather than dynamic conflict resolution techniques, e.g. based on priorities or heuristics. We aim at creating an integrated database for later queries in contrast to solely evaluate a policy decision. In addition, the complexity of code systems in an ABAC-oriented policy scheme can only be managed practically with policies of the same type. Therefore, the PMS is intended to be integrated into a workflow that implements the principle of "security is a process". This allows for a mitigation or ideally a correction of faulty states by a policy planner. A preventive treatment of policy conflicts by means of an iterative correction of a policy is ensured by recognizing these conflicts of the policy management system. The PMS' persist module returns potential conflicts with other policies and makes sure that only valid policies are registered.

Evaluation
To evaluate the practical utility of the policy management system (and of course the model including the policy conflicts), it will be applied in a technical experiment (cf. DSR evaluation types proposed by Peffers et al. [8]). This means that patient privacy policies are tested with Elektronische FallAkte (EFA), which is a special kind of an electronic health record. The EFA principle is specified as a distributed treatment documentation that provides a standardized structured and integrated view of a patient's medical data. Distributed means that different treating physicians view and update that data. The basic idea behind the EFA initiative launched by German hospitals and clinics in 2006 is to share a treatment case including the patient's billing and treatment data with treatment facilities of a region. Thus, general practitioners as well as physicians of a hospital are able to access electronic documents relevant to treatment [28].
A consent is -in addition to the data protection requirement of obtaining permission -a basic construct, in order to open an EFA instance for a patient. The currently profiled patient privacy policy of the EFA (the so-called Enhanced Patient Privacy Consent -EPPC) consists of an HL7 Clinical Document Architecture (CDA) document [29] which in turn includes a computable policy (the so-called EPPC Patient Privacy Policy encoded with XACML). In this way, important metadata for a treatment case (CDA) is strictly separated from the actual authorization list (XACML) [30] (cf. Figure 5).

16
-All rules and constraints that are given in the Privacy Consent Direct also apply to the Enhanced Patient Privacy Consent Document.
-All rules with regard to cardinality and configuration given below co constrain the Privacy Consent Directives specification.

IHE Connectathon
Several manufacturers of health-IT systems have agreed to test their current EFA implementations on the IHE Europe Connectathon in Bochum, Germany [31]. Three manufacturers tested the consent option with EPPC additionally to the EFA conformance tests. The five-day event, conducted annually by IHE, aims to interoperate with health information systems and issue certificates of conformity to IHE profiles. Compliance with the current specification for the EFA (almost an implementation profile based on different IHE profiles of the "IT Infrastructure Domain") is tested with regard to behavior and function. A test case is carried out as follows: Two test partners have to find each other and configure their systems as a client or server system in a defined IP network. Depending on how a test case dictates, one system sends a SOAP message [32] to the other. All messages are checked by the so-called test monitors with regard to the specifications of IHE and are stored for verification purposes. This also means that the client system as well as the server system must be able to send and process specification-compliant messages in order to pass a test case. For the duration of the event, the systems can also be modified, for example, to repeat a failed test under other conditions.

Setup and Execution
All defined ontologies of our policy model are registered with the PMS' validation module. Furthermore, the following states are pre-configured in the prototype: • An attending physician can collect, process and use identification data as well as medical data within the scope of a medical admission of patient. • An attending physician can access the application "FallAkte".
• The "FallAkte" application uses the "IHE XDS.b" application system to register and distribute diagnostic reports and images. • Policy attribute relationships as they are defined in Section 4.3 are registered with the PMS. The verification of an EPPC document includes, on the server side, the separation into a Resource Access Policy and Access Control Policy. After the separation, both artifacts are transferred into the policy model by means of the Extensible Stylesheet Language (XSL) [34] which then allows various checks to identify policy clashes (cf. Section 4.2 and Section 4.3). Finally, both policies are tested against reference policies.

Test Results
When the EPPC documents were tested by the PMS, it turned out that the activation of reference policies failed. This means that the test rules could not be applied because the Resource Access Policy and Access Control Policy of an EPPC document did not match with a suitable Resource Behavior Policy and Information Access Policy. The policy model required a modification in order to cope with structured data types for expressing subjects and objects as they are used in an EPPC document.
Objects are defined by an EFA purpose. The construct of the purpose binds a medical case to a patient -that is, all data that is available in a treatment context. In the case of EFA, this is implemented by so-called folder codes. A folder code, e.g. a coded diagnosis, describes an EFA instance in more detail and restricts the processing of a case record according to the intended purpose-of-use and need-to-know principle. If a patient agrees to the treatment, the agreed purpose-of-use must refer to one or more Access Control Policies. Finally, the ihe:FolderCode must be defined as a subtype of the purpose of an Access Control Policy in order to establish the necessary linkage to our policy model. The following RDF graph shows an example of structured data types used for subjects and objects: After the necessary corrections re-tests revealed that all EPPC documents were semantically valid, i.e. no policy conflicts were present and the opening of a case record can be achieved.
The main limitation of the evaluation is that not all types of policy conflicts could be tested. Testing for comprehensive policy conflicts requires a certain number of policies that must be maintained in the PMS. However, the evaluation shows that security policies from practice can be analyzed by means of our policy model and policy conflict definitions.

Concluding Remarks
This work aims at providing contributions to a comprehensive information security management in the hospital by addressing policy conflicts when accessing protected health information. Security policies in a hospital can capture access demands from treating physicians and assistants. The recognition of policy clashes can make sure that information security constraints are brought to the access control level. The new approach presented in this work describes policies using terminology services. RDFS constructs allow for the definition and later querying of specific policy conflicts, such as domain conflicts. This complements an ABAC-based policy infrastructure.
An introduced policy management system in this work shows a comprehensive integration of the developed policy model and can detect policy clashes. Thus, it provides an advantageous verification tool for policy authors.
An exemplary patient privacy consent that inherently features a multi-dimensional policy was used for an evaluation of the policy management system. It presents how this policy type can be validated against and integrated with access control policies. However, the policy management system was evaluated with just a small number of policies. To use it in operation requires the conduct of additional performance tests. Especially with a large number of policies, querying the policy net needs a robust graph handling.
Further investigation is needed for providing support for common analysis on access demands. The policy model perfectly fits to handle structured queries (e.g. why is someone allowed to print a lab report in the laboratory information system). A frontend with a selection of predefined SPARQL queries that can be applied on a candidate policy should be developed. This hides complexity of RDF syntax from policy authors. Besides, a domain-specific language might ease the description of new policies instead of using RDF languages not known to policy authors.