Difference between revisions of "ACWP Motivation"

From IHE Wiki
Jump to navigation Jump to search
Line 23: Line 23:
  
 
== Change Requests ==
 
== Change Requests ==
place your change requests here...
+
:TC090213 (decision): the objective of the WP to provide direction for future IHE profiles should explicitely be mentioned
 +
 
 +
: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...)

Revision as of 15:13, 13 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 regulations 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)
  • 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 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.

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 legitimacy 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.

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. 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.



Discussion

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. Joerg.caumanns 15:49, 27 January 2009 (UTC)
done. It should be discussed if dedicated sections should be added to certain sections. Joerg.caumanns 12:29, 28 January 2009 (UTC)

Change Requests

TC090213 (decision): the objective of the WP to provide direction for future IHE profiles should explicitely be mentioned
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...)