User Roles and Permissions for HIPAA

What You'll Learn

This article explains how to use Knack's user roles and permissions system to protect PHI in your HIPAA app. It covers how to design roles, assign page access, filter records to the logged-in user, and avoid common mistakes.

This article focuses on HIPAA-specific guidance. For general information on how user roles work in Knack, see User Management Fundamentals.

Why Roles Matter for HIPAA

HIPAA requires that access to PHI be limited to authorized individuals — and only to the extent they need it to do their job. In Knack, user roles are the primary way you enforce this.

Every person who logs in to your app should be assigned a role that determines what pages they can see, what records they can access, and what actions they can take. Without roles, all logged-in users see the same data — which almost certainly violates the Minimum Necessary Rule.

Designing Roles for a HIPAA App

Start by identifying the types of people who will use your app and what each group needs to do. Common examples in healthcare apps:

• Patient — views their own records, submits intake forms, sees appointment history
• Receptionist — views appointment schedules, edits contact info, checks patients in
• Provider — views clinical records, adds notes, reviews lab results
• Billing — views payment records and insurance info, doesn't see clinical notes
• Admin — manages users, views reports, has broader access for operational oversight

Each of these should be a separate user role in Knack. Don't create a single role that gives everyone the same access level.

📘

More roles = more control. It's better to start with more granular roles and relax access later than to start with broad access and try to tighten it up. Adding restrictions after users are already in the system is harder and riskier.

Controlling Page Access

Each page in your Knack app can be assigned to one or more user roles. Only users with the assigned role can access that page.

• Create separate pages for each role's workflow. A provider's dashboard and a receptionist's check-in page should be different pages, even if they pull from the same tables.
• Use login-protected pages for anything that displays PHI. See How to Create a Login-Protected Page for setup instructions.
• Review page permissions after making changes to your app. Adding a new page or element is easy to forget to lock down.

For more detail on managing page access, see How to Manage User Role Access

Filtering Records to the Logged-In User

Page-level permissions control which pages a user can see. But within a page, you also need to control which records are displayed. A patient logging into a portal should only see their own records — not every patient's data.

Knack handles this through source filters on elements. When you add a table, list, or details element to a page, you can filter it to show only records connected to the logged-in user.

This requires:

• A connection field between the records table and the user role table
• A source filter on the element set to "is the logged-in user" or "is connected to the logged-in user"

For step-by-step instructions, see Show Records Connected to the Logged-In User.

For apps where users belong to a group (like a clinic or department), you can filter records to the logged-in user's group instead. See Show Records Connected To The Logged-In User's Company Or Other Group.

Restricting Edit and Delete Actions

Controlling what records a user can see is only half the picture. You also need to control what they can do.

• Only add edit or delete actions to elements where the user role genuinely needs those capabilities
• A patient role should be able to view their records but probably shouldn't be able to delete them
• A receptionist may need to edit contact info but shouldn't be able to modify clinical notes

Remember: roles give builders the capability to restrict access. They don't automatically restrict anything. You need to explicitly configure what each role can see and do on each page.

Common Mistakes

• Using one role for all users. This gives everyone the same access to every page and record. Always create separate roles for different access levels.
• Forgetting to set source filters. Without source filters, a patient logging in could see every patient's records on a shared page.
• Adding edit/delete actions by default. Not every user needs to modify data. Only grant write access where it's required.
• Not testing as each role. After configuring roles, log in as a test user for each role and verify they can only see and do what's intended.

Next Steps

• Authentication Best Practices — Add 2FA, SSO, and strong passwords on top of your role structure
• Minimum Necessary Rule — Understand the HIPAA principle behind access restrictions
• Protected Pages Best Practices — Additional guidance on securing pages with logins