Difference between revisions of "Role-Based Access Control (RBAC) Use Cases"
m |
|||
| (21 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Back to: [[Community-Based_Collaborative_Care| CBCC Main Page]] > [[CBCC_Use_Cases| CBCC Use Cases]] | Back to: [[Community-Based_Collaborative_Care| CBCC Main Page]] > [[CBCC_Use_Cases| CBCC Use Cases]] | ||
| − | See also: [[Glossary of Consent Terms]] for | + | Back to: [[Security#Documents| Back to Main Security WG]] > [[Requirement_Analysis|Requirements Analysis]]> [[Security Use Cases]] |
| + | |||
| + | See also: [[Glossary of Consent Terms]] for definition of acronyms and terms. | ||
---- | ---- | ||
| Line 11: | Line 13: | ||
** "'''read, M.A.R. (medication administration record)'''" allows the user the see the medication administered to a patient. | ** "'''read, M.A.R. (medication administration record)'''" allows the user the see the medication administered to a patient. | ||
** "'''create, Registration'''" allows a clerk to register a patient by creating a registration/encounter record | ** "'''create, Registration'''" allows a clerk to register a patient by creating a registration/encounter record | ||
| − | ===Benefits | + | ===RBAC Benefits for Privacy Protection of Protected Health Information (PHI)=== |
| − | * Even though it does not take into account specific patient preferences, RBAC ensures that only specific user roles have access to patient information and clinical functionality (e.g. admission clerks cannot view pharmacy prescriptions). | + | * Even though it does not take into account specific patient preferences, RBAC ensures that only specific user roles have access to patient information and clinical functionality (e.g. admission clerks cannot view pharmacy prescriptions). |
| − | =Use Cases= | + | =Authorization Use Cases= |
| − | == | + | == Allow Functionality (based on role) == |
Based on the functional role of the user logged in, the healthcare information system will limit access only to those operations (e.g. append, create, read, update, delete, execute) and functions (identified using an object id) that are allowed for that role. | Based on the functional role of the user logged in, the healthcare information system will limit access only to those operations (e.g. append, create, read, update, delete, execute) and functions (identified using an object id) that are allowed for that role. | ||
| + | * This use case is a type of [[Security_Use_Cases#Authorize_users_and_systems| Authorize users and systems]] use case | ||
===Pre-condition=== | ===Pre-condition=== | ||
| − | This use case would apply to a situation where both the application and the security systems are in the same organization or in different organizations. | + | This use case would apply to a situation where both the application and the security systems are in the same organization or in different organizations using consistent functional roles. |
| + | *[[Security_Use_Cases#Authenticate_users_and_systems| Authenticate users and systems]] use case | ||
===Basic scenario=== | ===Basic scenario=== | ||
| − | A user logs in, the application identifies the functional group or role for the user. Based on the user's role, the application interrogates the security systems for the functions allowed for the role. The security system stores the permissions associated with the role and it can specify whether the user can access specific functionality. Based on the results provided by the security system, the application displays to the users only those areas of functionality that prescribed by their functional role. | + | A user logs in, the application identifies the functional group or role for the user. Based on the user's role, the application interrogates the security systems for the functions allowed for the role. The security system stores the permissions associated with the role and it can specify whether the user can access specific functionality. Based on the results provided by the security system, the application displays to the users only those areas of functionality that prescribed by their functional role. |
| − | |||
===Actors=== | ===Actors=== | ||
| Line 31: | Line 34: | ||
* Security System | * Security System | ||
| − | == Mask Information == | + | == Mask Information (based on user role) == |
| − | Based on their functional role, users can view(read),create, update, delete, or act (execute) on information contained in a patient's record. While the role of the user may limit their access to specific patient record information - limiting it to the information required to perform the job as specified by the role - | + | Based on their functional role, users can view(read),create, update, delete, or act (execute) on information contained in a patient's record. While the role of the user may limit their access to specific patient record information - limiting it to the information required to perform the job as specified by the role. |
| + | * This use case is a type of [[Security_Use_Cases#Authorize_users_and_systems| Authorize users and systems]] use case | ||
| + | ===Pre-condition=== | ||
| + | This use case would apply to a situation where both the application and the security systems are in the same organization or in different organizations using consistent functional roles. | ||
| + | *[[Security_Use_Cases#Authenticate_users_and_systems| Authenticate users and systems]] use case | ||
===Basic Scenario=== | ===Basic Scenario=== | ||
The user inquires the Personal Health Record system, based on the role the system provides the information specified by the permissions assigned to the user's role. | The user inquires the Personal Health Record system, based on the role the system provides the information specified by the permissions assigned to the user's role. | ||
| Line 40: | Line 47: | ||
* EHR System (EHRS) | * EHR System (EHRS) | ||
* Security System | * Security System | ||
| + | |||
| + | |||
| + | |||
| + | Back to: [[Security| Security Main Page]] or [[Security|Back to Meetings]] | ||
Latest revision as of 20:06, 18 August 2009
Back to: CBCC Main Page > CBCC Use Cases
Back to: Back to Main Security WG > Requirements Analysis> Security Use Cases
See also: Glossary of Consent Terms for definition of acronyms and terms.
Contents
Introduction
The following use cases are based on the RBAC specification.
Each type of user in a healthcare organization has a specified "role" which consists of "permissions" to perform certain functions and access specific data. While the set of permissions assigned to each role is based on local policy (enterprise-wide, jurisdiction-wide, etc.), the operation and the functions/information to which they apply, are standardized by HL7 as a normative specification. The functional roles for healthcare users are specified as an informative specification.
- Sample permissions:
- "read, M.A.R. (medication administration record)" allows the user the see the medication administered to a patient.
- "create, Registration" allows a clerk to register a patient by creating a registration/encounter record
RBAC Benefits for Privacy Protection of Protected Health Information (PHI)
- Even though it does not take into account specific patient preferences, RBAC ensures that only specific user roles have access to patient information and clinical functionality (e.g. admission clerks cannot view pharmacy prescriptions).
Authorization Use Cases
Allow Functionality (based on role)
Based on the functional role of the user logged in, the healthcare information system will limit access only to those operations (e.g. append, create, read, update, delete, execute) and functions (identified using an object id) that are allowed for that role.
- This use case is a type of Authorize users and systems use case
Pre-condition
This use case would apply to a situation where both the application and the security systems are in the same organization or in different organizations using consistent functional roles.
- Authenticate users and systems use case
Basic scenario
A user logs in, the application identifies the functional group or role for the user. Based on the user's role, the application interrogates the security systems for the functions allowed for the role. The security system stores the permissions associated with the role and it can specify whether the user can access specific functionality. Based on the results provided by the security system, the application displays to the users only those areas of functionality that prescribed by their functional role.
Actors
- User
- Healthcare Application
- Security System
Mask Information (based on user role)
Based on their functional role, users can view(read),create, update, delete, or act (execute) on information contained in a patient's record. While the role of the user may limit their access to specific patient record information - limiting it to the information required to perform the job as specified by the role.
- This use case is a type of Authorize users and systems use case
Pre-condition
This use case would apply to a situation where both the application and the security systems are in the same organization or in different organizations using consistent functional roles.
- Authenticate users and systems use case
Basic Scenario
The user inquires the Personal Health Record system, based on the role the system provides the information specified by the permissions assigned to the user's role.
Actors
- User
- EHR System (EHRS)
- Security System
Back to: Security Main Page or Back to Meetings
