Setting up the ePCR - Incident Status

Setting up the ePCR - Incident Status

Purpose Statement

Role-Based Restrictions for Incident Status Changes provides administrators with granular control over which user roles can transition incidents to specific statuses within the ePCR workflow. This feature ensures that only authorized personnel can advance incidents through critical stages—particularly those affecting billing, quality assurance, and documentation completion—preventing unauthorized modifications and maintaining workflow integrity throughout the incident lifecycle.

Background Information

In many EMS agencies, the incident workflow includes multiple stages from initial documentation through final billing. Each stage represents a critical checkpoint in the revenue cycle and compliance process. Without proper controls, any user could inadvertently or intentionally change an incident status, potentially causing billing errors, disrupting QA processes, or creating compliance issues.
This feature addresses these challenges by allowing administrators to define exactly which roles have permission to transition incidents to and from specific statuses. For example, an agency can ensure that only billing staff can mark reports as "Ready for Billing" or "Billed," while field providers maintain access to operational statuses like "In Progress" and "Provider Completed."
Common Use Cases:
  • Restricting billing-related status changes to billing department staff only
  • Limiting QA-related statuses to quality assurance team members
  • Preventing field users from prematurely closing or finalizing reports
  • Maintaining separation of duties for compliance and audit purposes
Prerequisites:
  • Existing incident statuses configured in your system
  • Clearly defined user roles within your department
  • Understanding of your agency's incident workflow and approval processes

Prerequisites:
  • Administrative access to the Incident Documentation module
  • Understanding of your department's incident workflow requirements
  • Familiarity with user roles and their operational responsibilities

Required Permissions

To manage incident statuses, users must have the following permissions:
Setup/Configuration:
  • EMS Setup - Manage
  • Manage EMS Statuses - Allow
Note: Standard field users typically do not have these permissions. This functionality is generally restricted to administrators, system configurators, or designated training officers who manage system-wide settings.

Video


Step-by-Step Guide


1. Accessing Incident Status Configuration
  1. Navigate to Setup → ePCR → Incident Status Configuration from the main menu.


Begin by navigating to the Incident Status found within the EMS Setup of the Incident Documentation module.



2. The Incident Status list displays all existing statuses in your system, showing:
  • Status Name
  • Active/Inactive indicator
  • Action icons (View, Edit, Deactivate, Delete)


Here a list of all your existing Incident Status will appear.



3. Understanding Status Icons and Actions
  1. Review the status indicators and available actions:
    • Eye icon: Indicates a system-locked status that cannot be edited or deactivated (e.g., "In Progress" and "Provider Completed")
    • Pencil icon: Opens the edit modal for configuring role restrictions
    • X icon: Deactivates the status (makes it unavailable for selection)
    • Trash can icon: Permanently deletes the status from the system


The eye icon represents a locked status that can not be edited or deactivated.



4. Deactivating an Incident Status
  1. To deactivate a status, click the X icon next to the desired status. 


To Deactivate a status select on the x.



5. A confirmation modal appears asking you to confirm the deactivation.
  1. Click Yes to deactivate the status (it will no longer appear in status selection dropdowns but historical data remains intact).


A new modal will appear confirming you wish to deactivate the Incident Status.



6. Editing Role Restrictions for Existing Statuses
  1. Click the pencil icon next to the status you want to configure.


Select on the pencil icon to begin editing the incident status.



7. The Edit Status Configuration modal displays with the following sections:
  • Status Name: The name of the incident status (editable)
  • Allow Change To column: Controls which roles can change an incident TO this status
  • Allow Change From column: Controls which roles can change an incident FROM this status
  • To modify role permissions:
    • Each role appears as a row with toggle switches in both columns
    • Toggle ON (blue): Role has permission for this action
    • Toggle OFF (gray): Role is restricted from this action
    • Click any toggle to change its state

  • Use the column headers to sort roles alphabetically (ascending/descending) for easier navigation when managing multiple roles.
  • After making your changes, click Save to apply the new role restrictions. 


When editing you are able to edit the Status Name along with change the permission for roles to Allow to Change To or Change From the selected Status.



8. Deleting an Incident Status
  1. To delete a single status, click the trash can icon next to the status.


To delete an Incident Status select the Trash Can icon.



9. Alternatively, use checkboxes to select multiple statuses for bulk deletion.


Or using the check boxes you are able to bulk delete.



10. A confirmation modal appears asking you to confirm the deletion.
  1. Click Yes to permanently remove the status(es) from your system.
WarningWarning: Deleted statuses cannot be recovered.


If deleting a new modal will appear confirming you want to delete the selected Incident Status.



11. Creating a New Incident Status with Role Restrictions
  1. Click the Add button at the top of the Incident Status Configuration screen. 


Now to create a new Incident Status select the Add button.



12. The New Status Configuration modal opens with the following fields:
  • Status Name (required): Enter a descriptive name for the new status
  • Allow Change To column: Configure which roles can transition incidents TO this status
  • Allow Change From column: Configure which roles can transition incidents FROM this status
  • Enter a Status Name that clearly describes the workflow stage (e.g., "Ready for Billing," "Under QA Review," "Supervisor Approval Required"). 


After selecting Add a new Status Configuration modal will display, it is required to give a Status Name.



13. Use the toggle switches to configure permissions for each role:
  • By default, all roles have both "Change To" and "Change From" permissions enabled
  • Disable toggles to restrict specific roles from these actions
  • Consider your workflow requirements when setting restrictions
  • Review your configuration to ensure the correct roles have appropriate permissions.
  • Click Add to create the new status with the configured role restrictions. 


Click on Add Cancel



14. How Role Restrictions Are Enforced
  1. When a user attempts to change an incident status, the system performs the following validation:
    1. Checks the user's assigned role(s)
    2. Verifies if the role has "Allow Change To" permission for the target status
  2. Verifies if the role has "Allow Change From" permission for the current status


Click on Billed



  1. If either permission is denied, displays a warning message and prevents the status change


Click on Your current user role does not allow changing the status.



  1. Updating Incident Status from the EMS Incident List
    1. Only the enabled statuses for that role will populate to choose from.




Best Practices

Planning Your Status Restrictions:
  • Map out your complete incident workflow before configuring restrictions
  • Identify which roles need access to each status based on job responsibilities
  • Consider the full lifecycle from initial documentation through final billing
  • Document your permission structure for training and reference purposes
Separation of Duties:
  • Restrict billing-related statuses to billing department personnel only
  • Limit QA/audit statuses to quality assurance team members
  • Prevent field personnel from accessing administrative or financial statuses
  • Maintain clear boundaries between operational and administrative functions
Testing and Validation:
  • Test status changes with users from different roles before full deployment
  • Verify that restricted users receive clear error messages when attempting unauthorized changes
  • Ensure critical workflow statuses remain accessible to appropriate personnel
  • Conduct periodic audits to confirm restrictions align with current workflow needs
Role Management:
  • Review role assignments regularly to ensure users have appropriate access
  • Update status restrictions when organizational roles or responsibilities change
  • Create role-specific training materials explaining which statuses they can modify
  • Consider creating specialized roles for complex permission requirements
Common Mistakes to Avoid:
  • Don't over-restrict statuses—ensure users can complete their primary job functions
  • Avoid creating too many similar statuses with different restrictions (consolidate when possible)
  • Don't restrict "In Progress" or "Provider Completed" (system prevents this by design)
  • Don't delete statuses that are actively used in historical incidents
  • Avoid granting billing status access to non-billing personnel

Troubleshooting & FAQs

Q: I'm trying to change an incident status, but I'm getting an error message saying I don't have permission. What should I do?
A: This means your user role has been restricted from changing to or from that particular status. Contact your system administrator to verify if you need access to that status for your job responsibilities. If access is required, the administrator can modify the role restrictions in the Incident Status Configuration settings.

Q: Can I restrict the "In Progress" or "Provider Completed" statuses?
A: No, these two core statuses are system-locked and always accessible to all roles. This ensures field personnel can always document and complete incident reports regardless of other workflow restrictions. The eye icon next to these statuses indicates they cannot be edited or restricted.

Q: What happens if I deactivate a status that's currently assigned to existing incidents?
A: Deactivating a status makes it unavailable for future status changes, but it does not affect historical incidents that already have that status assigned. Those incidents retain their status value for reporting and compliance purposes. Users will not be able to select the deactivated status when changing incident statuses going forward.

Q: Can a user with multiple role assignments change statuses if one of their roles is restricted?
A: Yes, if a user has multiple roles assigned and at least one of those roles has permission for the status change, the user will be able to perform the action. The system checks all of a user's assigned roles when validating permissions.

Q: I accidentally deleted an incident status. Can I recover it?
A: No, deleted statuses cannot be recovered. However, historical incidents that used that status retain their data. If you need the status again, you must create a new status with the same name and configure its role restrictions. Consider deactivating statuses instead of deleting them if you may need them in the future.

Q: How do I know which roles currently have access to a specific status?
A: Click the edit (pencil) icon next to the status in the Incident Status Configuration screen. The Edit Status modal displays all roles with their current permission settings. Enabled (blue) toggles indicate the role has permission; disabled (gray) toggles indicate restrictions.

Q: Can I bulk edit role restrictions across multiple statuses?
A: Currently, role restrictions must be configured individually for each status. However, you can use the sorting functionality in the role permission columns to quickly review which roles have access across different statuses.

Q: What's the difference between "Allow Change To" and "Allow Change From" permissions?
A: "Allow Change To" controls whether a role can set an incident TO this status (e.g., marking an incident as "Ready for Billing"). "Allow Change From" controls whether a role can change an incident away FROM this status (e.g., moving an incident from "Billed" back to "Under Review"). Both permissions must be enabled for a role to freely move incidents in and out of a status.

Q: Will restricting status changes affect automated workflows or integrations?
A: Role-based restrictions apply to manual user actions within the ePCR system. Automated workflows and system integrations typically operate with elevated permissions and are not subject to these restrictions. Consult with your system administrator or First Due support if you have concerns about specific integrations.


    • Related Articles

    • Restrict Inspection Types based on Permissions by Level

      Purpose Statement This feature allows administrators to control which personnel can start and complete specific inspection types by assigning permission levels. The system separates Company Level Inspections from Fire Prevention Inspections, ensuring ...

    • Creating or Updating a Role: Permissions

      Purpose Statement The Permissions tab in First Due provides administrators with comprehensive control over user access rights, allowing them to grant or restrict specific capabilities within the platform. This feature ensures proper security ...

    • API User Setup

      Purpose Statement This article explains how to generate and manage API tokens within First Due, which are essential for establishing secure connections between First Due and external systems. API tokens enable automated data exchange, third-party ...

    • Admin > Field Management

      Purpose Statement Field Management enables administrators to configure and customize form fields across the First Due platform. This feature allows agencies to tailor data collection fields, set user permissions, and manage dropdown lists to meet ...

    • Creating or Updating a Role: Configuration

      Purpose Statement Roles and Permissions allow administrators to create and manage custom user roles within First Due. This feature enables departments to define specific access levels, security requirements, and operational permissions tailored to ...