Difference between revisions of "ACWP Motivation"
Jump to navigation
Jump to search
| (18 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | IHE White Paper on Access Control | + | [[ITI_Access_Control_White_Paper|IHE White Paper on Access Control]] |
== 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 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. | |
| − | |||
| − | |||
| − | |||
| − | |||
<hr> | <hr> | ||
| − | == | + | == 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. | |
| − | |||
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.