Difference between revisions of "WPAC Conclusion Policies and Attributes"
Jump to navigation
Jump to search
Line 48: | Line 48: | ||
==== Patient Attributes ==== | ==== Patient Attributes ==== | ||
− | * Patient attributes | + | * Patient attributes originate in the patient domain. They refer to the patient himself, his characteristics and wishes. Prominent examples include attributes concerning the sanity or age of the patient and attributes expressing his consents. |
* Example: ''"The patient documented his consent to use a certain medical application on his electronic health card."'' (patient consent attribute) | * Example: ''"The patient documented his consent to use a certain medical application on his electronic health card."'' (patient consent attribute) | ||
− | |||
=== Binding of Policies and Attributes=== | === Binding of Policies and Attributes=== |
Latest revision as of 11:12, 19 January 2009
IHE White Paper on Access Control
Conclusion: Policies and Attributes Needed
Policies
- Policies are the appropriate mean to express rules that govern the access to medical data and related applications and resources. The policies needed to meet the existing security and privacy requirements do originate in the patient, application and resource domain.
Patient Privacy Policy (patient domain)
- The patient privacy policy refers to all access rules implicitly or explicitly defined by the patient. The policy reflects his personal wishes concerning the processing and usage of his medical data.
- Example: "All doctors working in the cardiology department of hospital ABC are allowed to access my medical health record 123."
Application Policy (application domain)
- The application policy addresses the security and privacy requirements of medical applications, e.g. an electronic health record. The rules expressed within this policy derive from various sources, e.g. data protection laws and/or organizational policies.
- Example: "The electronic health record system can only be accessed by the medical staff of this hospital."
Resource (Data Protection) Policy (resource domain)
- The application policy addresses the security and privacy requirements of medical applications, e.g. an electronic health record. The rules expressed within this policy derive from various sources, e.g. data protection laws and/or organizational policies.
- Example: "The electronic health record system can only be accessed by the medical staff of this hospital."
Attributes
- Attributes serve as input parameters when policies are rendered into policy decisions. They are one of the main building blocks of a policy based access control framework and originate from most of the identified domains.
Subject Attributes
- Subject attributes do originate in the subject domain. They provide additional information on the subject that tries to access a resource. Subject attributes can be used to define and evaluate rules that refer to certain characteristics of the accessing subject. The most prominent example for a subject attributes is a role assignment.
- Example: "Dr. John Doe is a cardiologist." (role attribute assignment)
- The main source for subject attributes are standalone identity management systems or identity management components that are integrated into the HIS or similar systems.
Resource Attributes
- Resource attributes do originate in the resource domain. They provide information on the requested resource and are widely used in resource policies. A prominent example might be the confidentiality level of an accessed information object or the information type or class.
- Example: "A metadata entry for a medical information object shows that the requested resource contains sensitive medical information." (confidentiality level attribute)
- The main source for resource attributes are the resources as such. The attributes can often be derived from resource metadata (e. g. contained in registries).
Context Attributes
- Context attributes do originate in the context domain. They often refer to activities, purposes or the context of an intended resource access. Prominent examples are the activated roles that subjects are acting in or certain process or workflow steps.
- Example: "Medical information is requested within an emergency context." (emergency context attribute)
- The main attribute source can be identified in systems that control the information workflow, e.g. HIS or LIS.
Patient Attributes
- Patient attributes originate in the patient domain. They refer to the patient himself, his characteristics and wishes. Prominent examples include attributes concerning the sanity or age of the patient and attributes expressing his consents.
- Example: "The patient documented his consent to use a certain medical application on his electronic health card." (patient consent attribute)
Binding of Policies and Attributes
- A strong interdependency between policies and attributes does exist. Without the existence of appropriate attributes the application of rules contained within policies wouldn't be possible.
- The following figure tries to illustrate this interdependency:
- Rules contained within different policy types refer to one or more attribute. Often attributes from different domains are part of a single rule or rule set. Common relationships are illustrated with the help of bold lines.
- Example:
- Policy: All doctors working in the cardiology department of hospital ABC are allowed to access my medical health record 123.
- To render this patient privacy policy into a decision multiple attributes from different domains are needed:
- Subject attributes (assigned roles, assigned organizational units)
- Resource attributes (medical health record number)
- Attributes originate in different attribute sources. Common relationships are illustrated with the help of bold
lines.
Discussion
place issues to be discussed among the editorial team here...
Change Requests
place your change requests here...