User permissions

Introduction

You may be familiar with the permissions that Canvas has utilized in the past. These permissions only affected Django admin (the area accessed by www.<customer instance>.canvasmedical.com/admin) and not the Canvas app. For example, a user without the permission “Can change patient address” could not change patient addresses in Django admin, but could change patient addresses in the chart. Now, with the rollout of true user permissions, this is no longer the case. Customers can now restrict user actions in the actual Canvas app.

Key objectives

• You will learn the difference between object and model permissions
• You will learn how permissions in Canvas are structured
• You will learn how permissions are turned on
• You will learn how to set role-based permissions
• You will learn how to modify permissions by staff

Overview

Object vs model permissions

In Canvas, there are two kinds of permissions:

• Object permissions. “Object” in this case means “Patient”. Therefore these permissions control which users can access which patients. If a staff does not have access to a certain patient, they cannot access any data pertaining to that patient, with a few exceptions. Exceptions include: information that can be gathered from the main search bar (name, date of birth) and information in appointments that are scheduled for that patient.
• Model permissions. These essentially assign read/write vs. read only vs. no access for different parts of the app. If a staff has read/write access to the clinical chart, they can write notes, enter commands, mutate patient data, etc. If they have read-only access, they can see all clinical data but make no changes. If they have no access, they will not be able to see the clinical chart, nor any clinical data present in other parts of the app (like Labs, Imaging, etc.)

How permissions are structured

Both object and model permissions are assigned in Canvas via auth groups.

The way this works for model permissions is that an auth group is a collection of permissions. As an example, “Clinical write” is an auth group. It contains permissions such as “add note”, “change note”, “change imaging report” etc. Customers cannot assign these individual permissions to users, they can only assign the full auth group “Clinical write”.

The way this works for object permissions is that an auth group is tied to a patient group. If a user is assigned an auth group, then they have access to all patients in the corresponding patient group.

Step by step

How permissions are turned on

The steps to start using permissions are as follows:

1. Canvas turns on permissions in your instance
2. Canvas assigns one or more customer users access to “Staff permissions” and “Roles” in order to be able to change permissions on staff and roles.

In step 1, what will happen is, Canvas will run a management command in your instance. This management command will do the following:

• Turn on the permissions configs
• Grant all staff all auth groups
• Grant all roles all auth group

Why would the command grant everyone full permissions? This way when the command is run, there should be no change in user experience. All users will be able to do everything they can do today. This will prevent interruptions in work. In order for permissions to take effect, a customer administrator will need to start removing auth groups from staff and roles.

How to assign auth groups by role

For each role, customers can set default auth groups. This means: every time a new staff is created with that role, they will automatically inherit these auth groups.

Three important notes here:

• If the default auth groups are changed after a staff is created, it will have no impact on their assigned auth groups.
• If a role is added to a staff, they will be assigned any auth groups associated with that role which they do not already have.
• If a role is removed from a staff, no auth groups will be removed.

Step-by-step:

1. Select a role on Admin > Practice > Roles
   • As mentioned above, a user must be granted access to “Roles” by Canvas
2. Scroll to find "Default auth groups"
3. Move auth groups from "Available groups" to "Selected groups" (or vice versa) and save
4. Create a new staff with this role
5. Go to “Staff permissions”. You should see that the staff has the auth groups that you assigned to the role.

How to assign auth groups by staff

After staff are created, customers can change the auth groups for each staff member as well. This would be done as follows:

1. Navigate to Admin > Practice > Staff permissions and select the desired staff
   • As mentioned above, a user must be granted access to “Staff permissions” by Canvas
2. Select a staff member
3. Move auth groups from "Available groups" to "Selected groups" (or vice versa) and save.

How to assign object permissions

As mentioned above, object permissions are also assigned by auth groups. The following steps will explain how to create a new auth group that represents access to a set of patients, and then how to assign it to a staff or role.

1. Go to Admin > Practice > Patient groups
2. Click "Add new patient group +"
3. Give it a name like "United patients", select "Use for permissions" as True and click "Save".
   • Note: what this will do in the back end is automatically create an auth group with the same name as the patient group, in this case "United patients". If you do not click "Use for permissions", this will not create an auth group, and you will not be able to use it for permissions.
4. Go to Admin > Practice > Patient group members
5. Right now the patient group is empty, so we want to add some patients.
6. Click "Add patient group member +"
7. Add any number of desired patients to the patient group.

Now you have an auth group “United patients”. Any staff with access to that auth group will have access to the patients in that group.

In order to assign this auth group to a particular staff member or role, follow the steps above in “How to assign auth groups by role” and “How to assign auth groups by staff”.

For more on how to manage patient groups in Canvas, including using the SDK, please see Patient groups.

Functionality

The “All Patients” group

We have created one special auth group called the “All Patients” group. If a staff member has access to the “All Patients” auth group, then they have access to all patients, even though it is not tied to an underlying patient group as the previous section describes. The reason this was created is so that customers have a convenient way to assign certain users access to all patients without having to maintain a patient group up to date with all patients. For example, perhaps MD role always needs access to all patients. In that case, add the “All Patients” auth group to the MD role, and now all staff created with that role will automatically have access to all patients.

Note that for this functionality to work, the config ALL_PATIENTS_GROUP_ENABLED must be turned on. However, this is turned on as part of turning on permissions for your instance, so you do not need to take additional steps.

Available auth groups for model permissions

Canvas has built auth groups for model permissions. These are the only auth groups that customers can use for front end permissions at the moment. Here is the list:

• Schedule write: Allows the user to schedule new appointments and change appointment statuses.
• Profile read: Allows the user to read data on the patient profile, which is the page where demographics, addresses, etc. are placed. Without this group, the user will not be able to access the Patient profile at all, unless they have either the Patient create or Clinical read auth groups, which also give access at the moment.
• Profile write: Description: Allows the user to write data on the patient profile, which is the page where demographics, addresses, etc. are placed. Includes actions like running eligibility checks.
• Clinical read: Allows the user to read clinical data, both in the patient chart and in the panel views like "New labs", "New imaging", etc. Important note: because "Can view patient" is in this group, and that is the gateway permission to enter the Profile page, currently anyone with Clinical read should also get Profile read.
• Clinical write: Allows the user to write clinical data, both in the patient chart (e.g. creating new notes, etc.) and in the panel views like "New labs", "New imaging" (e.g. reviewing results, etc.). Also includes ability to change appointment statuses (because that is related to note state changes).
• Revenue access: Allows the user to access the revenue model and access claims and revenue data on the Patient profile.
• Patient Create: Allows the user to create new patients from the "New patient" button on the schedule page.
• Document Read: Allows the user the see patient's administrative documents
• Document Write: Allows the user to edit or remove patient's administrative documents
• Data integration Access: Allows the user to access data integration and take actions like upload files, link files to a patient, etc. Currently, Clinical write auth group is also required to 
• Printing Access: Allows the user to use fast print actions, which essentially consists of any link that includes "Print" in the title.
• Tasking Access: Can view and modify tasks.

How object permissions impact the user experience

• Navigating to the patient chart
  • If a user does not have access to a patient, they will not be able to navigate to their chart or profile. Links to the patient's chart or profile will be grayed out. If the user navigates to the URL for a patient's chart, they will encounter a generic screen with a message like "You do not have permission to view this data".
• Filtered patient search
  • This refers to searching for a patient in the search bar which can be found on the schedule page.
  • This search will be filtered so that patients the user does not have access to do not appear in the initial search. For example, if the user does not have access to patient "John Doe", then "John Doe" will not appear in initial search results if the user searches "John"
  • However, if the user clicks "See all patients" (at the bottom of the search results), then the user will see patients they do not have access to (alongside inactive or deceased patients that currently appear here). The reason for this is so that the user can verify that a patient is already in the system, and request access to them, rather than creating a new patient.
• Creating a new patient
  • Object permissions will not have an impact on creating a new patient. What is important to note here is that users will continue to get warnings regarding duplicate patients if they try to create a new patient with the same name and DOB as an existing patient, whether or not they have access to the existing patient
• Filtered data in panel views
  • This refers to all the panel views that can be navigated to from the icons on the top right of the Schedule page including: Tasks, Refill requests, New labs, New imaging, New consult reports, Patient messages, Outstanding referrals, New uncategorized reports, and Inpatient stays.
  • The data for patients the user does not have access to will be filtered out of these views.
  • Please note that even items assigned to staff will not be visible to them if they do not have access to the patient. Therefore it is critical to ensure that important clinical data like new lab results are not assigned to staff who do not have access to the patient.
•  Filtered list of patients in patients view
  • This refers to the Patients view, which displays a list of all patients that can be navigated to from the main hamburger menu.
  • Similar to above, patients to whom users don't have access will be filtered out of the patients view.

•