ACWP Objective and Outline: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Newer edit →
New page: IHE White Paper on Access Control == Objective and Outline of this White Paper == * This document looks at the issues of how to define and implement ac...
 
Line 3: Line 3:
== Objective and Outline of this White Paper ==
== Objective and Outline of this White Paper ==


* This document looks at the issues of how to define and implement access control in healthcare networks that might even span multiple affinity domains. The focus is mainly on issues that relate to the IT architecture and the flow of messages that are required for a destributed access control sceanrio. Therefore this paper will deal with the problems of (1) how to discover the access control policies that hold for a certain treatment scenario and (2) how to obtain these policies and all required information (3) how to evaluate and enforce access control policies.
This document looks at the issues of how to define and implement access control in healthcare networks that might even span multiple affinity domains. The focus is mainly on issues that relate to the IT architecture and the flow of messages that are required for a destributed access control sceanrio. Therefore this paper will deal with the problems of  
# how to apply established principles of secure design and SOA security on the design of access control systems,
# how to model an access control solution in a way that is well suited for reasoning and evaluation, and  
# how to deploy an access control solution using well understood patterns and interoperable system components.  


* The concepts presented in this paper are evolving rapidly and are subject to manifold national and international standardization efforts. The goal is to expose the common concepts from all of these activities, match them with experiences from existing healthcare networks, and define common technological building blocks which allow for a variety of strategies and policies to be used. The building blocks are described on a conceptual level and on an integration level based on current state-of-the-art in security token handling. Is is assumed that the design of the overall healthcare data exchange infrastructure is oriented towars the principles of a service-oriented architectiure (SOA). It is further more assumed that a dedicated security architecture is set up which provides a circle-of-trust among the security and business services which are deployed among independend affinity domains.  
Given the strong focus on models and methodologies for designing access control solutions for cross-enterprise data exchange in healthcare the primarly intended audience are system architects and developers who are involved in the planning, design, and realization of regional healthcare networks and compareable infrastructures where the secure exchange of patient related data among enterprises is an issue.


=== Objective ===
The concepts presented in this paper are evolving rapidly and are subject to manifold national and international standardization efforts. The goal is to expose the common concepts from all of these activities, match them with experiences from existing healthcare networks, and define common design mehodologies and technological building blocks which allow for a variety of strategies and policies to be used. The building blocks are described on a conceptual level and on an integration level based on current state-of-the-art in security token handling. Is is assumed that the design of the overall healthcare data exchange infrastructure is oriented towars the principles of a service-oriented architectiure (SOA). It is further more assumed that a dedicated security architecture is set up which provides a circle-of-trust among the security and business services which are deployed among independend affinity domains.
* This paper is based on some basic observations:
** there is no one-fits-all solution for access control in federated healthcare environments because the “optimized” deployment of policy administration and policy information – and the respective data flows - depend on the paradigms and the semantics of the policies used.
** the hardest architectural problems to be solved are obtaining the right policies and the required information for policy decision. Everything else is covered by standards and can be done in a rather generic way.


* Therefore this white paper does not provide a single deployment of ACS and its building blocks among static domains. It rather provides healthcare system architects with a model and a corresponding methodology:
The rest of this white paper is organized as follows:
** The model describes how the building blocks of a distributed access control solution can be desribed in a manner that is both deployment and implementation independent.
'''As the ToC is still subject of discussion the outline will be added later'''
** The methodology defines how system architects can use the model to reason about different realization opportunites in order to discover the most appropriate deployment and flow of control with respect to the given application architectures requirements.
 
=== Outline ===
* The rest of this white paper is organized as follows:
** The generic ACS model defined in the previous section does not cover any healthcare-specific aspects. These are subject of chapter 2. Among the issues discussed are the role of the patient and different varieties of policies that are typical for healthcare scenarios.
** Based on the observations on specific healthcare issues, an extension/specialization of the generic model is introduced in section 3. This model is suitable to describe almost any authorization model - even if different paradigms (e. g. DAC and RBAC) are used simultanously.
** Examples for the application of the model are given in chapter 4. It is described how common access control scnearios can be expressed using the various model elements.
** Section 5 describes a methodology on how to work with the model in order to discover possible options for the deployment and flow of control of a given access control problem.
** After an access control soulution has been modelled on an abstract level, the next step is the mapping of the model elements onto physical building blocks (actors and transaction). Section 5 introduces well accepted standards for these building blocks and reasons about different implementation options.




Revision as of 11:44, 27 January 2009

IHE White Paper on Access Control

Objective and Outline of this White Paper

This document looks at the issues of how to define and implement access control in healthcare networks that might even span multiple affinity domains. The focus is mainly on issues that relate to the IT architecture and the flow of messages that are required for a destributed access control sceanrio. Therefore this paper will deal with the problems of

  1. how to apply established principles of secure design and SOA security on the design of access control systems,
  2. how to model an access control solution in a way that is well suited for reasoning and evaluation, and
  3. how to deploy an access control solution using well understood patterns and interoperable system components.

Given the strong focus on models and methodologies for designing access control solutions for cross-enterprise data exchange in healthcare the primarly intended audience are system architects and developers who are involved in the planning, design, and realization of regional healthcare networks and compareable infrastructures where the secure exchange of patient related data among enterprises is an issue.

The concepts presented in this paper are evolving rapidly and are subject to manifold national and international standardization efforts. The goal is to expose the common concepts from all of these activities, match them with experiences from existing healthcare networks, and define common design mehodologies and technological building blocks which allow for a variety of strategies and policies to be used. The building blocks are described on a conceptual level and on an integration level based on current state-of-the-art in security token handling. Is is assumed that the design of the overall healthcare data exchange infrastructure is oriented towars the principles of a service-oriented architectiure (SOA). It is further more assumed that a dedicated security architecture is set up which provides a circle-of-trust among the security and business services which are deployed among independend affinity domains.

The rest of this white paper is organized as follows: As the ToC is still subject of discussion the outline will be added later


Discussion

place issues to be discussed among the editorial team here...

Change Requests

place your change requests here...

Retrieved from "http://wiki.ihe.net/index.php?title=ACWP_Objective_and_Outline&oldid=29546"