Security in an EMR is critical. As healthcare organizations grow, it only becomes more important. Canvas’s permissions model provides a flexible framework, allowing customers to both restrict actions within the application and limit access to specific groups of patients.

Overview

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.)

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

Model permissions

Auth groups for model permissions are managed by Canvas. They cannot be altered. We provide the following auth groups:

• 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.

Object permissions

Follow these instructions to create patient groups. When creating them, there is an option to use them for permissions. Selecting yes will automatically create object-based auth groups.

Object permissions will impact user experience in the following ways:

• 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 “You do not have permission to view this data”.

• Filtered patient search: This search will be filtered so that patients the user does not have access to do not appear in the initial search. 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. 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: Items assigned to staff will not be visible to them if they do not have access to the patient. 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: The patients view will only include patients that the user has access to.

Every instance has a default auth group called “All Patients”. If a staff member has access to the “All Patients” auth group, they will have access to all patients, even though it is not tied to an underlying patient group.

Setting permissions

Default permissions based on role

When configuring roles, you can set default auth groups. Every time a new staff is created with that role, they will automatically inherit these auth groups.

Updates to roles have the following impact on auth groups assigned to staff:

• If the default auth groups are changed after a staff is created, it will have no impact on their assigned auth groups.

• If a new role is added to a staff profile, 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. You must update the staff permissions of that staff member.

Updating Staff Permissions

Admins can assign permissions to an individual user rather than an entire role.

• Go to Practice: Staff Permissions under Settings

• Select User

• To add permissions for the user

  • Select group under Available Groups

  • Double click the group or click the right arrow to move the group to Chosen Groups

• To remove permission from use

  • Select group under Chosen Groups

  • Double click the group or click the left arrow to move the group to Available Groups

    Press cmd for Mac or ctrl for PC to select multiple options from either group

• Click Save

Manually adding and removing auth groups

If you need to update permissions, or override the defaults set based on role, you can change the auth groups for each staff member as well. To do this, navigate to Staff Permissions in your admin menu, select the staff member, and move the group from available groups to chosen groups or vice versa.

FAQ & Troubleshooting

Q: What happens if a user loses access to a patient they were previously working with?

A: If a user loses access to a patient, they will no longer be able to view that patient's chart, profile, or any associated data. Links to the patient will be grayed out, and direct navigation attempts will show a "You do not have permission to view this data" message. Any tasks or items previously assigned to them for that patient will no longer be visible.

Q: Can I create custom auth groups beyond the predefined ones?

A: No, model permission auth groups are managed by Canvas and cannot be altered or customized. However, you can create object permission auth groups by creating patient groups and selecting the option to use them for permissions.

Q: Why can some users see patients in the "See all patients" search results even if they don't have access?

A: This is by design to allow users to verify that a patient already exists in the system before creating a duplicate. It helps prevent the creation of duplicate patient records while still maintaining security by preventing access to the actual patient data.

Q: What's the difference between removing a role and removing individual auth groups?

A: Removing a role from a user does not automatically remove any auth groups—you must manually update the staff permissions. However, adding a new role will automatically assign any auth groups associated with that role that the user doesn't already have.

Q: How do I ensure that clinical staff can see important lab results?

A: Make sure that staff with Clinical Read or Clinical Write permissions also have access to the patients for whom lab results are being received. Object permissions will filter out items assigned to staff if they don't have access to the specific patient.

Q: Can a user have both read and write permissions for the same area?

A: Yes, write permissions typically include read access. For example, Clinical Write includes the ability to both read and write clinical data. You don't need to assign both Clinical Read and Clinical Write to the same user.

Related Resources

• Creating Patient Groups - Learn how to set up patient groups for object-level permissions

• Role Management in Canvas - Comprehensive guide to setting up and managing user roles

• Data Integration Overview - Understanding how data access permissions affect imported documents and lab results

• Staff Management - General guidance on adding and managing staff members in Canvas

• Security Best Practices - Recommended approaches for maintaining EMR security and compliance

Keywords: user permissions, auth groups, staff access, patient access, role-based permissions, object permissions, model permissions, security, EMR access control

Categories: User Management, Security, Administrative Settings, Staff Configuration