Difference between revisions of "ACWP Motivation"

From IHE Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
== Motivation ==
 
== Motivation ==
  
The exchange of medical data among enterprises is subject of multiple IHE integration profiles. E. g. XDS allows for sharing data among physicians within an affinity domain while XCA even enables the sharing of medical data across multiple of such domains. As with any processing of personal data, various regulations apply to these data-sharing use cases. These regulations point out different aspects of medical data processing and therefore follow different objectives:  
+
The exchange of medical data among enterprises is subject of multiple IHE integration profiles. E. g. XDS allows for sharing data among physicians within an affinity domain while XCA even enables the sharing of medical data across multiple of such domains. As with any processing of personal data, various constraints (laws, regulations, and policies) apply to these data-sharing use cases. These regulations point out different aspects of medical data processing and therefore follow different objectives:  
* protecting the patient's privacy and right to self-determination (e. g. HIPPA in the US and the European privacy directive)  
+
* protecting the patient's privacy and right to self-determination (e. g. HIPAA in the US and the European privacy directive)
 +
* full compliance to professional codes of conduct, such as professional discretion
 
* ensuring the integrity and proper handling of health data (e. g. regulations for the handling of radiologic data)  
 
* ensuring the integrity and proper handling of health data (e. g. regulations for the handling of radiologic data)  
 
* enforcing an adequate risk management within organizations (e. g. KonTraG in Germany)  
 
* enforcing an adequate risk management within organizations (e. g. KonTraG in Germany)  
  
With respect to the prevention of illegal disclosure it is crucial that providers of medical data can be sure that data consuming parties enforce the common understanding of the purposes of use that data was originally provided for. Therefore the definition and enforcement of access rules for medical data and services throughout clinical workflows is a precondition for any co-operative patient treatment.  
+
With respect to the prevention of inappropriate disclosure it is crucial that providers of medical data can be sure that data consuming parties enforce access constraints conformant to the purposes under which that data was provided. Therefore the definition and enforcement of access rules for medical data and services throughout clinical workflows is a precondition for any cooperative patient treatment.  
  
Perimeter protection (e. g. firewalls) and mutual node authentication (e. g. as provided by ATNA) are laying ground for any secure healthcare infrastructure, but they fall short if fine-grained access rules have to be enforced or if the decision on the [Zulässigkeit] of a resource access depends on information that is either encoded within the (potentially encrypted) message payload or even not part of the message at all.
+
Perimeter protection (e. g. firewalls) and mutual node authentication (e. g. as provided by ATNA) are laying ground for any secure healthcare infrastructure, but they fall short if fine-grained access rules - potentially making use of multiple policies and distributed attribute sources - have to be enforced.
  
This white paper points out how access control services should be integrated into healthcare IT infrastructures and how IHE can be used to support such policy-aware healthcare solutions.
+
This white paper points out (1) how access control services should be integrated into healthcare IT infrastructures, (2) how IHE can be used to support such policy-aware healthcare solutions, and (3) where there are opportunities for new IHE Profiles. A dedicated focus will be on opportunities for preserving patient safety by keeping data accessible, even in cases where the security subsystem is partly or totally unavailable.
  
  
 
<hr>
 
<hr>
  
== Discussion ==
+
== Open Issues ==
:in the January f2f ''patient safety'' was pointed out as yet another aspect that should be mentioned. A link to this issue (just one sentence) should be part of the introduction. [[User:Joerg.caumanns|Joerg.caumanns]] 15:49, 27 January 2009 (UTC)
+
:TC090213 (integrate): Healthcare IT is characterized by independent data managing systems (HIS, PACS, ...) without a central point of control. There is no single point for controling the security of protected resources, therefore ACS must be federable.
  
== Change Requests ==
+
:TC090213 (add): audit trails as a reactive access control measure should be mentioned when appropriate (but no more...)
place your change requests here...
+
 
 +
== Closed Issues ==
 +
:TC090213 (decision): the objective of the WP to provide direction for future IHE profiles should explicitely be mentioned
 +
 
 +
:in the January f2f ''patient safety'' was pointed out as yet another aspect that should be mentioned. A link to this issue (just one sentence) should be part of the introduction.

Latest revision as of 14:41, 19 February 2009

IHE White Paper on Access Control

Motivation

The exchange of medical data among enterprises is subject of multiple IHE integration profiles. E. g. XDS allows for sharing data among physicians within an affinity domain while XCA even enables the sharing of medical data across multiple of such domains. As with any processing of personal data, various constraints (laws, regulations, and policies) apply to these data-sharing use cases. These regulations point out different aspects of medical data processing and therefore follow different objectives:

  • protecting the patient's privacy and right to self-determination (e. g. HIPAA in the US and the European privacy directive)
  • full compliance to professional codes of conduct, such as professional discretion
  • ensuring the integrity and proper handling of health data (e. g. regulations for the handling of radiologic data)
  • enforcing an adequate risk management within organizations (e. g. KonTraG in Germany)

With respect to the prevention of inappropriate disclosure it is crucial that providers of medical data can be sure that data consuming parties enforce access constraints conformant to the purposes under which that data was provided. Therefore the definition and enforcement of access rules for medical data and services throughout clinical workflows is a precondition for any cooperative patient treatment.

Perimeter protection (e. g. firewalls) and mutual node authentication (e. g. as provided by ATNA) are laying ground for any secure healthcare infrastructure, but they fall short if fine-grained access rules - potentially making use of multiple policies and distributed attribute sources - have to be enforced.

This white paper points out (1) how access control services should be integrated into healthcare IT infrastructures, (2) how IHE can be used to support such policy-aware healthcare solutions, and (3) where there are opportunities for new IHE Profiles. A dedicated focus will be on opportunities for preserving patient safety by keeping data accessible, even in cases where the security subsystem is partly or totally unavailable.



Open Issues

TC090213 (integrate): Healthcare IT is characterized by independent data managing systems (HIS, PACS, ...) without a central point of control. There is no single point for controling the security of protected resources, therefore ACS must be federable.
TC090213 (add): audit trails as a reactive access control measure should be mentioned when appropriate (but no more...)

Closed Issues

TC090213 (decision): the objective of the WP to provide direction for future IHE profiles should explicitely be mentioned
in the January f2f patient safety was pointed out as yet another aspect that should be mentioned. A link to this issue (just one sentence) should be part of the introduction.