ACWP Objective and Outline: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
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...
 
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[ITI_Access_Control_White_Paper|IHE White Paper on Access Control]]
[[ITI_Access_Control_White_Paper|IHE White Paper on Access Control]]


== Objective and Outline of this White Paper ==
== Objective and Outline of the 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 comparable 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.  
* 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:
Is is assumed that the design of the overall healthcare data exchange infrastructure is aligned to the principles of a service-oriented architecture (SOA). It is furthermore 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. Nevertheless even if the focus is on cross-enterprise health information exchange (HIE) all concepts provided by this white paper can be scaled down to the organization or even department level.
** 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.  
** 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 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.
'''As the ToC is still subject of discussion the outline will be added later'''
** 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.




<hr>
<hr>


== Discussion ==
== Open Issues ==
place issues to be discussed among the editorial team here...
 
== Closed Issues ==
:Is the intended audience to narrow? If other user groups are to be addressed, how would this affect the ToC and the level of detail? [[User:Joerg.caumanns|Joerg.caumanns]] 16:47, 27 January 2009 (UTC)
::the definition of the audience is agreed upon (TCon 090213) [[User:Joerg.caumanns|Joerg.caumanns]] 20:27, 13 February 2009 (UTC)
 
:TC090213 (change): WP is ''aligned to SOA''


== Change Requests ==
:TC090213 (consensus): the focus of the WP is on how to use an AC architecture in the context of cross-enterprise scenarios based on XDS. Nevertheless the AC framework can easily be downscaled to be applicable intra-enterprise, too.
place your change requests here...

Latest revision as of 14:54, 19 February 2009

IHE White Paper on Access Control

Objective and Outline of the 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 comparable 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 aligned to the principles of a service-oriented architecture (SOA). It is furthermore 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. Nevertheless even if the focus is on cross-enterprise health information exchange (HIE) all concepts provided by this white paper can be scaled down to the organization or even department level.

The rest of this white paper is organized as follows:

As the ToC is still subject of discussion the outline will be added later



Open Issues

Closed Issues

Is the intended audience to narrow? If other user groups are to be addressed, how would this affect the ToC and the level of detail? Joerg.caumanns 16:47, 27 January 2009 (UTC)
the definition of the audience is agreed upon (TCon 090213) Joerg.caumanns 20:27, 13 February 2009 (UTC)
TC090213 (change): WP is aligned to SOA
TC090213 (consensus): the focus of the WP is on how to use an AC architecture in the context of cross-enterprise scenarios based on XDS. Nevertheless the AC framework can easily be downscaled to be applicable intra-enterprise, too.