Jump to Section: [Create a Role] [Example]
Create a role
- Click Administration.
- Select Users.
- Right-click the User Administration Dialog and select Edit Roles.
- There are currently about 340 different permissions to chose from for a given role.
- Along the right side of the screen Role Members contains a list of all users.
- Click the + to Expand Module Permissions.
Users that are assigned to the currently selected role are shown with a check.
Under the dropdown is a tree view that will allow you to explore the various permissions in each of the three branches:
- Module Permissions
- Report Access
- Clinic Access
Module Permissions
| Administration | Pertains to the general administration of the system, including but not limited to adding, editing, and deleting information in General Information, Doctors, and Carriers. |
| Attachments |
Set of permissions for the management of Case Attachments. |
| Case | Set of permissions for the management of general case information. |
| Charges and Documentation | Set of permissions for entering charges. |
| Demographics | Set of permissions that allow you to specify exactly what part of a patient's personal information the user can see and edit. |
| Dialogs | This important set of permissions specifies which screens a user can access. For example, if a user has permission to edit the patient's address but does not have permission to access the Case, they will not be able to change the address. |
| Financial | Set of permissions pertaining to the financial aspects of the patient's case. |
| Form Letters | Set of permissions revolving around defining and sending form letters. |
| General | Set of permissions that do not fit into any of the other categories. |
| Notes | Set of permissions controlling note access, such as Case, Billing, Reminder, etc. |
|
Scheduling |
Set of permissions for the schedule. |
- Report Access permissions are organized exactly like the Report Tree and allow users to specify the reports this role can access.
- Clinic Access is a list of all the clinics within your organization and allows the user to select which clinics this particular role can access.
Each permission in the tree has a check box containing one of three different values.
Each role can either grant the permission, deny it or not say anything at all about it (indeterminate).
Roles Menu
| Granted | |
| Indeterminate (neither Granted nor Denied) | |
| Denied |
When a user is assigned a set of roles, all the roles are merged together to arrive at a final set of permissions for that user. When permissions are merged, the user will have permission for all operations specifically Granted by at least one role as long as no other role specifically Denies it.
Any permission that is left as Indeterminate after the roles are merged will the leave user unable to perform that particular action. In order for a user to have permission for a particular area, they must be Granted permission by at least one of the roles. If a role explicitly denies access to permission, however, that will override any Granted permission.
NOTE: In most security schemes, an explicit denial of permission is rarely used. Rather, permission schemes are comprised of a series of Granted permissions, since anything left Indeterminate will ultimately be denied.
Example
Assume that you have two employees who are techs: one who helps in the front office (we’ll call them a Super Tech) and one who doesn't (we’ll call them a regular Tech). The Therapy Technician role fits the Tech but is too limited for the Super Tech. Your first instinct might be to create a new role, Super Therapy Technician, for that employee, perhaps by cloning the Therapy Technician role and adding extra permissions. You might find, however, that giving the Super Tech the Therapy Technician role and the Front Office Assistant role is exactly what you need since this covers all the functions this employee does.
Let’s take this example one step further and expand our operation to two clinics with Super Tech working at Clinic A and the Tech working at Clinic B. Now assume you want both employees only to have permissions for the clinic where they work. Here you would create two additional roles - one called Clinic A and another called Clinic B. The only permission that either of these roles has is access to a specific clinic.
So, Super Tech working at Clinic A would have the roles:
Therapy Technician, Front Office Assistant, Clinic A, and Tech working at Clinic B would have the roles: Therapy Technician, Clinic B
The advantage of this approach is that if you later determine that the Therapy Technician role needs to be changed, you can do so and the change will automatically apply to both techs. If you had created a Super Tech role, you would have had to modify it as well, creating more work and the possibility of mistakes. Again, the idea behind roles is to keep the number of unique roles to a minimum