User Management
From TAPASWiki
TAPAS has a user management system to insure that the correct access to information, privacy and security are maintained. This system will also allow for groupings of users into logical collections based on access rights based on roles and organizational groupings.
Contents |
Definitions
Users
Users are actors in the system who have access to the system. They must be defined in the system and granted access through our security model.
Patients, at this time, are not considered users of the system. This could be an extension in the future.
Roles
A position/function/profession associated with a given user, e.g., MD, MOA, nurse, administrator etc.
Roles limit the access of a user to appropriate sections of the TAPAS system and to patient information.
Groups
An organization or sub-organization providing medical services.
For example, in a virtual practice (multiple offices connected together) these may be a collection of staff from a single office.
TAPAS Roles - System Implementation
It is proposed that, for security reasons, at the Java security level that roles and groups are implmented simply as roles. Therefore, as part of TAPAS, users will be able to have predefined (system) roles and instance defined (user) roles.
System roles would limit access to aspects of TAPAS. User roles would correspond to the idea of a group and would allow easier access to subsets of information (such as alerts)
Users will have 0 to many system roles and 0 to many user defined roles.
NOTE: This will be filled in more detail by Joel. ***Please add Technical Spec from your draft.***
Roles
These cannot be changed by the user as they will provide access to functions that are appropriate only to certain roles - e.g. MDs can prescribe medications, MOAs cannot. We have pre-defined several roles in TAPAS:
- Clinicians:
- Physicians
- Nurses
- MOAs
- System Administrators
These can be changed in the future
Role Based Access in TAPAS
In the current release we are going to distinguish role access only based on three roles: System Administrator, MOA and Physician. Nurses will have the same access as physicians.
Future iterations will allow more granular limits and this will be based on our privacy and security model as well as clinical consultation.
NOTE: There is also the question, beyond "role" access, of whether a patient summary is restricted, this is discussed under patient confidentiality.
The list of accessible screens are as follows, broken down by workspace and patient tabs:
| ROLE | Workspace Tabs |
| Physician / Nurse: | messages, alerts, referrals, specialists, groups, settings |
| MOA: | messages, alerts, referrals, specialists, groups, settings |
| Admin | messages, user management, Role management, Group Management, Settings |
| ROLE | Patient Tabs |
| Physician / Nurse: | Edit access to all tabs |
| MOA: | Summary, Demographics, alerts, referrals |
| Admin | No tabs. The systems administrator role does not have access to clinical data. They will not be able to search on patients at all. |
In the PDA Application (Tapeta) the user has full view access to the patient summary.
Groups
Groups are more fluid and dynamic. They reflect "sub organizations" within the practice network - that is groups of users that correspond to an smaller group within the whole. Many of these will be implementation specific. These user groups can be accessed when assigning alerts, messages, etc.
Group Maintenance
Allowing users to assign themselves to a group is problematic from a security point of view. However, the fluid nature of practice may require that people join certain groups temporarily and we want to allow users to have that flexibility without compromising security. This is a requirement of the Clinical Working Group. In order to meet these requirements, we can allow users that already belong to a specific group to "grant" other users access to become a member of this group. This will provide the flexibility that groups need without compromising the trust model that groups need.
Group Examples and Uses
Groups will be useful for messaging, referrals and patient alerts. They will allow users to direct information to multiple people and allow people to share the responsibility for the performance of a task over time. Through the use of groups, schedules need not be known, just that a group is responsible for a task. For example:
Clinic Referral Management
Referrals are assigned a "referral manager" in TAPAS - someone who is responsible to follow through the referral co-ordination to completion.
An MD could assign the referral management to the staff group for his or her clinic. All MOAs in South Clinic, for example, would belong to "South Clinic MOAs" and can share the load of referral management, depending on their schedule as they do with paper referrals in a typical practice. If step one of a referal was not completed today, whomever might be working the next day would be able to see what the status of all shared referrals might be. The MOA would not have to reassign referrals manually, they would be shared.
Alerts: On Call Doctors
One key group for the system's first implementation would be the "On Call Doctors" group - any alert that is assigned to this group would be accessible to all users. This is a more generic implementation of On Call Alerts than what was originally described in the plan and would allow for more future flexibility.
Messaging
The messaging app could be extended to support sending messages to groups of users. Instead of picking multiple people, a single group could be selected and a message sent to them. Faster and more accurate / consistent.
Active Status
Users should be able to be active or inactive. This is particularly important for locums and other temporary staff who may need access to the system but, for security reasons, should only have access when on staff.
The administrator role will have the ability to activate / deactivate users.
User Interface Description
Each role will have a focus tab associated with it. Each focus tab will be a "workspace" tab for that role.
| ROLE | Focus Tab |
| MD | Tab will include things like: my messages, my settings, my alerts, my referrals, my groups |
| MOA | Tab will include things like: my messages, referral management, specialist managment, my settings |
| Admin | Admin function tabs will include: my messages, user management, Role management, Group Management, My Settings |
See an example in the Admin UI page for the pages that manage user roles.
NOTE: There will be duplication in these tabs. There are at least two other solutions:
- Create an additional tab that has all the "My" tabs on it - my messages, my settings, etc
- Have a primary role that has all the "My" tabs on it
At this point it is quite reasonable to have the duplication. There will be few power users of the system that will have multiple roles (eg MOA and Admin) where this will be an issue. It might benificial to workflow to have access to these tabs from either section of work.
