Clinician Directory & Roles
Relevant source files
The following files were used as context for generating this wiki page:
- src/js/entities-service/entities/clinicians.js
- src/js/views/clinicians/sidebar/clinician-sidebar_views.js
- src/js/views/clinicians/clinician-modal/clinician-modal_views.js
- test/integration/clinicians/clinicians-all.js
- test/integration/clinicians/clinician-sidebar.js
- src/js/i18n/en-US.yml
- test/support/api/clinicians.js
The Clinician Directory is a management module within the RoundingWell frontend designed to view, search, and administer clinician accounts. It provides administrative tools to create new clinician profiles, manage their assignments to teams and workspaces, and define their organizational roles and permissions.
This system ensures that clinicians are properly provisioned with access to specific patient worklists and workflows. A clinician's "Active" status is determined by the presence of a team assignment, workspace membership, and evidence of a previous login (last active timestamp).
Sources: src/js/entities-service/entities/clinicians.js:107-113, src/js/views/clinicians/sidebar/clinician-sidebar_views.js:77-79, test/integration/clinicians/clinicians-all.js:41-55
Clinician Data Model
The clinician entity is a Backbone-based model managed via a central entity service. It utilizes a UUID generated from the clinician's email address to maintain unique identity across the system.
Model Attributes & Logic
| Attribute | Type | Description |
|---|---|---|
name | String | Full name of the clinician. Required for validation. |
email | String | Unique email address used for identity and login. |
enabled | Boolean | Administrative flag to enable or disable account access. |
last_active_at | Timestamp | The last time the clinician signed into the application. |
_role | Resource | Relationship to a Role entity defining permissions. |
_team | Resource | Relationship to a Team entity. |
_workspaces | Array | List of workspace resources the clinician belongs to. |
Sources: src/js/entities-service/entities/clinicians.js:11-37, test/support/api/clinicians.js:18-20
Identity and Lifecycle
Clinicians have three primary states of visibility and activity:
- Active: Has an assigned team, belongs to at least one workspace, and has logged in previously.
- Pending: Account created but lacks one or more requirements for full activity (e.g., never logged in).
- Disabled: Account manually deactivated by an administrator; roles and teams become read-only.
Sources: src/js/entities-service/entities/clinicians.js:107-113, test/integration/clinicians/clinicians-all.js:84-106
The state machine illustrates how clinician accounts transition between Pending, Active, and Disabled based on configuration and user activity.
Sources: src/js/entities-service/entities/clinicians.js:107-116, src/js/views/clinicians/sidebar/clinician-sidebar_views.js:203-211
Directory Architecture
The Directory is implemented using Marionette.js views organized into a list view, a management sidebar, and a creation modal.
List View and Filtering
The main directory displays a table of clinicians including their Name, Workspaces, Role/Team, and Last Sign In. It supports "Find in List" functionality which filters results in real-time based on name, role, team, or workspace strings.
Sources: test/integration/clinicians/clinicians-all.js:12-39, test/integration/clinicians/clinicians-all.js:133-165
Clinician Sidebar
The sidebar (SidebarView) serves as the primary interface for editing existing clinicians. It is composed of multiple sub-regions:
- Identity: Name and Email fields. These are locked (disabled) if the clinician has already been active.
- State Management: Toggle between Enabled and Disabled status.
- Relationship Management: Components for updating Roles, Teams, and Workspace memberships.
- Contextual Actions: A link to the "Owned By" worklist for that specific clinician within their current workspace.
Sources: src/js/views/clinicians/sidebar/clinician-sidebar_views.js:123-145, test/integration/clinicians/clinician-sidebar.js:25-55
Sequence of events when an administrator updates a clinician's team assignment through the sidebar.
Sources: src/js/entities-service/entities/clinicians.js:45-53, src/js/views/clinicians/sidebar/clinician-sidebar_views.js:169-175
Roles and Permissions
RoundingWell uses a role-based access control system. A clinician's role determines their ability to perform specific actions across the frontend.
Permissions Enforcement
The Clinician model provides a can(prop) method to check for specific permission strings stored within the associated role resource.
| Permission | Scope |
|---|---|
work:own | Ability to be assigned as an owner of actions or flows. |
work:owned:manage | Ability to manage work owned by themselves or their team. |
admin | Access to administrative tools including the Clinician Directory. |
Sources: src/js/entities-service/entities/clinicians.js:82-86, test/integration/clinicians/clinicians-all.js:118-125, test/integration/clinicians/clinician-sidebar.js:256-270
Role-Specific Visibility
The application filters clinician lists based on status and permissions. For example, the filterAssignable() method in the Clinicians.Collection returns only clinicians who are Active, Enabled, and possess the work:own permission.
Sources: src/js/entities-service/entities/clinicians.js:123-134
Clinician Provisioning Flow
Provisioning a new clinician involves a multi-step modal interface where administrators define the core identity and initial access levels.
Workflow for adding a new clinician to the organization.
Sources: src/js/views/clinicians/clinician-modal/clinician-modal_views.js:77-113, test/integration/clinicians/clinician-modal.js:12-90
Workspace and Team Association
Clinicians must be associated with at least one workspace to access patient data. When a clinician is removed from a workspace, the system handles the re-assignment of their owned work:
- Selection: Admin chooses to remove a clinician from a specific workspace.
- Warning: A modal warns that any flows or actions owned by this clinician in that workspace will be re-assigned to their Team.
- Execution: A
DELETErequest is sent to the workspace-clinician relationship endpoint.
Sources: test/integration/clinicians/clinician-sidebar.js:130-155, src/js/i18n/en-US.yml:32-34
Summary
The Clinician Directory & Roles system acts as the central administrative hub for managing user access. By combining strict identity validation (email-based UUIDs) with flexible role and team assignments, the system ensures that patient care tasks are managed by authorized personnel while providing administrators with clear indicators of account readiness and activity status.