Roles and Access
ClaimPod has four roles. Which one you hold decides what appears in your sidebar, and the split is not the usual “administrators see everything”.
| Role | What it is for |
|---|---|
| User | The billing work. Patients, visits, claims, remittances, transactions, queues. |
| Manager | Workload distribution: queues, assignments, reporting. |
| Administrator | Configuring ClaimPod: users, clients, rules, imports, reference data. |
| Superadmin | Everything, including the access logs, and the only role that can grant or remove Administrator. |
Administrators Cannot See Patient Data
Section titled “Administrators Cannot See Patient Data”This surprises people, so it is worth stating plainly: an Administrator has no Patients page, no Visits, no Claims, no Remittances and no Transactions. They are not in the sidebar, and opening one by link shows You Don’t Have Access.
That is deliberate. Someone has to manage accounts, rules and imports, and that job does not require seeing anyone’s medical record. Keeping the two apart means the person with the most configuration power has the least exposure to protected health information, and the audit trail stays meaningful rather than recording that the administrator opened everything.
The practical consequence: the person who sets ClaimPod up cannot test the billing screens. Whoever does that work needs the User role as well.
Who Grants Administrator
Section titled “Who Grants Administrator”Only a Superadmin can give someone the Administrator role or take it away, whether on a user, on a group or when inviting. An Administrator sees the role locked in a user’s or a group’s roles, with “Only a Superadmin can grant or remove the Administrator role.”, and is not offered it when inviting someone. The same lock covers changing an Administrator’s email. A group that gives the Administrator role is locked for anyone but a Superadmin, with “Only a Superadmin can change a group that holds the Administrator role.”: its members, roles and clients, and deleting it.
A few other locks protect accounts the same way:
| Lock | What it reads |
|---|---|
| A Superadmin’s account can be changed only by a Superadmin | “Only a Superadmin can change a Superadmin’s account.” |
| Nobody changes their own group memberships | “You can’t add yourself to a group or remove yourself from one.” |
| Nobody changes the roles of a group they belong to | “You can’t change the roles of a group you belong to.” |
What Managers See
Section titled “What Managers See”A Manager gets the dashboard, the work queues list with its assignments, analytics, reference data and the client list, but no patient-level screens either. Opening a queue to work its items needs the User role, because the items are about patients and claims, so a Manager or an Administrator who follows a link into one sees You Don’t Have Access. It is a coordination role: deciding who works what, not working it.
Screens Outside Your Sidebar
Section titled “Screens Outside Your Sidebar”The sidebar shows what your role is meant to use, which is not quite everything it can open. A plain User can open Clients, which lists only the clients they are assigned to or reach through a group, and Rules, read-only, from a link, though neither is in their sidebar. Both are there for an Administrator, who can change them.
Access Is Granted Per Client
Section titled “Access Is Granted Per Client”Your role says what kind of thing you can do. Client access says which practices you can do it to. An administrator grants it by assigning you to a client, or by adding you to a group that can open the client. Holding the User role grants nothing on its own until one of those happens.
If you sign in and see the No Client Access notice, that is what happened: the account exists, the grant does not.