Overview

Compliance actions encompass both formal and informal enforcement activities (often referred to as enforcement actions). 

Examples of compliance actions include:

• Warning Letter

• Notice of Violation

• Administrative Order

• Consent Decree

Compliance actions have the following features:

• A unique compliance action number, which is automatically assigned to each action. The numbering scheme is based on the settings for the compliance action type set by a system administrator.

• Classification into different types and categories, which are set up by a system administrator. The numbering scheme assigned to a compliance action is based on the compliance action type and can be configured by a system administrator.

• A compliance action status (see description of statuses below).

• An action date, which is the date that the compliance action was entered or issued.

• The ability to reference one or more violations (recorded via an evaluation) which triggered or substantiated the compliance action.

• Compliance Schedules that can be defined for reporting or other requirements that must be fulfilled.

• The ability to define fines and stipulations. Fines may be assessed and invoiced as part of the compliance action issuance or after issuance. Stipulations may also be specified indicating potential fines that the responsible party may incur (e.g., per event, per month, per occurrence).

• The option to be designated as confidential, which will limit access to the compliance action record by non-privileged users.

• The ability to supersede (or be superseded by) another compliance action. This may occur when escalating a compliance action from an informal action to a formal action. When a compliance action is entered or issued that supersedes another action, the superseded compliance action status is updated to Superseded.

• Other shared attributes such as Events, Documents, Contacts, and Program Components.

Compliance Action Status

The status of a Compliance action tracks where the compliance action is in its life cycle. All functional area items in nVIRO have three major status categories: Draft, Active, and Closed.

The valid status transitions are defined in system configuration. Some implementations may include additional statuses not listed below.

Security and Permissions

The ability to change the status of an item is dependent upon the user's permissions and the status of the item. In general, if the item is in an active status and the current user has assigned work related to the item (such as being the assigned processor, or having an active workflow task related to the item), then the item will be editable.

See Security Groups for additional information.

On this page

Related Content

• Compliance Action Types

• Documents

• Violations

• Schedules

• Program Components