Difference between revisions of "ACWP Motivation"

From IHE Wiki
Jump to navigation Jump to search
 
(11 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
== Motivation ==
 
== Motivation ==
−
=== Privacy and Data Security ===
 
  
−
* medical data is classified as personal data and therefore demands for protection with respect to confidentiality
+
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:  
−
* various legal restrictions apply to the use of medical data. These regulations have different motivation:
+
* protecting the patient's privacy and right to self-determination (e. g. HIPAA in the US and the European privacy directive)
−
** 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)
+
* ensuring the integrity and proper handling of health data (e. g. regulations for the handling of radiologic data)  
−
** enforcing the prevention of risks (e. g. law suits) within organizations (e. g. KonTraG in Germany)
+
* enforcing an adequate risk management within organizations (e. g. KonTraG in Germany)  
−
* these regulations can bee seen (and implemented) as sets of rules (policies) that have to be considered whenever patient data is processed either within a medical organization or among a network of medical organizations
 
−
* the authority for these policies is distributed among the stakeholders (e. g. patient, medical staff, governmental organizations) and policies come with forms (e. g. written consent, laws and regulations, medical treatment contracts, job profiles), but the responsibility for their proper enforcement is always with the organizations that hold and process the data
 
−
* therefore: Each organization that holds and/or processes medical data has to think about restricting access to this data with respect to the policies that hold for this data
 
  
−
=== Access Control vs. Perimeter Protection ===
+
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 is the modern form of a medieval city wall: It hinders intruders from entering the city by limiting entry points and thus providing the ability to control every incoming subject. Among the drawbacks of this security means is that it hinders trade because the flow of people and goods into and out of the city is limited by the throughoutput of the city gate and the performance of the gate keepers.
+
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.
−
* The same holds for medical organizations; as long as patient data is not to be exchanged with external entities, perimeter protection is appropriate as the major and maybe even only security means
 
−
* As soon as data is to be exchanged among medical organizations, gates have to be provided and the city wall gets porous for co-operating partners as well as for attackers. Therefore in the first run gate passing must be restricted to entities that are assumed to be trustworthy (e. g. by implementing bi-directional node authentication). In most cases it is nevertheless not appropriate to allow any entity that regularly passes the gate to access any resource within the organization's IT infrastructure. Therefore more fine grained restrictions on resource access must be provided in order to implement all policies that hold for resources rather than for the resource managing system (e. g. everybody is allowed to enter a bank building but not everybody is allowed to draw money from every account).
 
−
* Conclusion: Security can only be obtained by an appropriate mixture of measures:
 
−
** perimeter protection makes sure that external communication is limited to dedicated gateways which can be observed and where the trustworthiness of incoming requests can be evaluated
 
−
** node authentication restricts access to resource maintaining systems to parties that are authenticated and assumed to be regular users
 
−
** access control restricts access to the protected resources itself to authorized users within well defined contexts of use (e. g. for certain purposes)
 
  
−
=== Needs-to-Know Principle ===
+
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.
  
−
[[Image:WPAC_need_to_know_v01.png|Needs-to-Know Principle]]
 
  
−
* the objective of access control is to enable every medical staff member to perform all data processing operations that he needs to do in order to fill his role within the medical treatment process - but no more!
+
<hr>
−
* the organization of labour and separation of duty within a medical organization or a healthcare network determines who is allowed to perform what (medical) activities within which contexts (e. g. for what purpuses)
 
−
* Permissions for the processing of medical data are derived from the permitted activities of a role within a certain context. Following the needs-to-know principle these permissions reflect the operations on medical data which are part of the activity.
 
−
* Access control should always follow the needs-to-know principle. Therefore the objective is that the set of permitted operations of a user always contains the permissions that are required to fill the current job role.
 
−
* The needs-to-know principle couples permissions with the organization of labour. Therefore the permissions granted by an access control system that follows the needs-to-know principle are always as compliant with legal regulations and privacy restrictions as the underlying organization of work. If the organization of work within a medical organization or within a medical network violates legal regulations or a patient's consent, the access control system will implicitly do so as well.
 
−
* The needs-to-know principle has impact on the design of an access control system, because it differentiates between restrictions on the assignment of people to activities and restrictions on the accessability of medical data within certain activities. '''In an ideal access control system a patient consent should always focus on the first (e. g. by opting-in or -out certain people, job roles, or organizations from performing a medical activity) while resource protection should focus on the second (e. g. by stating clear rules which activities require which permissions)'''.
 
  
−
'''''Authors Note:''' We will come back to this during the discussion of the various access control paradigms, because this statement implies a strong relationship between patient consents and discretionary access control''
+
== 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.
  
−
<hr>
+
:TC090213 (add): audit trails as a reactive access control measure should be mentioned when appropriate (but no more...)
  
−
== Discussion ==
+
== Closed Issues ==
−
place issues to be discussed among the editorial team here...
+
:TC090213 (decision): the objective of the WP to provide direction for future IHE profiles should explicitely be mentioned
  
−
== Change Requests ==
+
: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.
−
place your change requests here...
 

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.
Retrieved from "http://wiki.ihe.net/index.php?title=ACWP_Motivation&oldid=30516"