Case Processing Overview

Learn about the stages and states in the Vault Safety Case Processing lifecycle.

Note Beginning with 24R1 in April 2024 and for all subsequent releases, Vault Safety General Release Help content is moving to a new site. Test the new site using Limited Release content.

Note Depending on your Admin's configuration, object, field, and section labels, lifecycle states, and workflows may differ from the general information on this page. Refer to your organization's business processes for guidance.

About Case Due Dates

Vault Safety automatically calculates and assigns the regulatory reporting due date for Cases. The due date is based on the Case New Info Date, and the applicable reporting ruleset. Your Vault may also have custom due date overrides for studies, which are configurable by your Admin.

If there is no matching rule set, the due date will default to 30 days for non-serious Cases and 15 days for serious Cases.

Due dates are calculated when Cases are first opened and, depending on your Admin’s configuration, can be recalculated during Case lifecycle state changes. Refer to your standard operating procedures for more information.

Authorized users can also trigger due date calculation manually using the Recalculate Due Date user action from the All Actions (All Actions) menu on the Case.

Case States

The default Case Processing lifecycle occurs in five stages. Each stage is made up of one or more lifecycle states and associated user tasks. Each task is available to members in the appropriate user role.

The Lifecycle Stages Chevron panel at the top of the Case page shows what stage the Case is in:

case-status-bar
Case Status Panel

Intake

See AER States for AER object type states. The following table summarizes the Case Intake states:

Lifecycle State Description
New This state is for newly created Cases.
Importing This state is for Cases that are being imported from an E2B file. In this state, Vault Safety is in the process of extracting E2B data.
Promoting The Promoting state is intended for system use only and is not included in the Case Intake workflow.
Error This state is for Cases for which an E2B file could not be imported due to an error. The user who initiated the import can view the error message in the E2B import notification.

Following Inbox Item or AER promotion, Cases are ready to be triaged. In this state, the Triage task becomes available, during which the seriousness of the primary adverse event is assessed. Vault Safety uses the seriousness to calculate the Case priority and reporting due date. Complete Case Triage provides more information.

Entry

The following table summarizes the Entry states:

Lifecycle State Description
Data Entry This state is for Cases that are ready for users to perform data entry and enter the full case details.

Enter Case Data provides more information.

Revision This state is for Cases that have entered the Case Revision workflow to modify a previously Approved Case. In this state, the Case is unlocked and available for users to revise or add information.

Revise an Approved Case provides more information.

QC This state is for Cases that are ready for a quality check to review the Case data entry and ensure complete and accurate information has been entered.

Review Case Data Entry provides more information.

Note Due to default system behaviour on all date fields, if a partial date is entered (for example, YYYY or YYYY/MM), you cannot update the field to include the first day of the month (YYYY/MM/01). As a workaround, update the date to any other precise date (for example, YYYY/MM/02), and then select the first of the month. The field is updated.

Review

In Vault Safety’s default lifecycle and workflow configuration, non-expedited Cases skip the Review stage and go directly to the Submission stage.

The following table summarizes the Review states:

Lifecycle State Description
Medical Coding This state is for Cases that require a designated Medical Coding state between QC and Medical Review.

Note that this state is not included in the default Case Processing workflow. If your organization requires this state, an administrator can add it to the Case Processing lifecycle and workflow.

Medical Review This state is for Cases that are ready for medical review. In this state, authorized users can perform the following tasks, as required:
  • Compose or update the narrative document.
  • Assess and enter the causality assessment result for each linked adverse event and suspect product.
  • Assess and enter a single case diagnosis.
  • Ensure the case is entered correctly and enters or edits the expectedness and seriousness criteria.

Enter a Case Assessment provides more information.

The Medical Review state also triggers case unblinding, if required. The unblinding states are described below.

Unblinding

If a Case requires unblinding prior to medical review, it will automatically trigger the Unblinding workflow. By default, the Unblinding workflow starts after the QC task is completed, however, your vault may have a custom configuration.

The following table summarizes the Unblinding states:

Lifecycle State Description
Unblinding This state is for Cases that have triggered the Unblinding workflow. Cases remain in this state until an authorized user chooses to break the blind or maintain the blind.

Manage Case Blinding provides more information.

End of Study Unblinding

This state is for follow-up Cases created by the system during a bulk unblind operation.

Bulk Unblind a Study provides more information.

Unblinded This state is for Cases that have been unblinded. Once a Case is unblinded, blind protection continues to mask sensitive study information for unauthorized users.

Manage Case Blinding provides more information.

Voiding

Lifecycle State Description
Voiding This state is for Cases that are in the process of being voided after initiating the Void Case action.
Void a Case provides more information.
Nullifying This state is for Cases that are in the process of being voided after initiating the Void Case action, and if previous Transmissions are being nullified as well.
Void a Case provides more information.

Submission

The following table summarizes the Submission states:

Lifecycle State Description
Approved This state is for Cases for which data entry and reviews are complete, and are ready for submission. Approve a Case provides more information.

Once a Case enters the Approved state, the system automatically generates any Submission and Distribution records, depending on the reporting rules configured in your vault.

The following pages provide more information on Submission and Distributions:

Approved Cases are locked from further changes prior to submission. However, users can still make changes to the Case by initiating the Case Revision workflow.

Once the submission process is complete, authorized users can close the Case.

Transmission Error This state is for Cases for which a transmission error occurred during electronic gateway distributions. Once a Case enters this state, you cannot close the Case until you resolve the transmission errors.
Validation Error This state is for transmissions for which validation error occurred during schema validation. When there are errors submitting to the gateway you can review and fix the errors. When configured, Transmissions in Validation Error status can be excluded from submission/distribution.

Complete

The following table summarizes the Complete states:

Lifecycle State Description
Closed This state is for Cases that have been closed, and therefore locked from further changes. Once a Case enters this state, the only way to revise the Case is to create a new version.

Close a Case provides more information.

Superseded This state is for Cases that are superseded by a newer version. When a Case has multiple versions, all versions except the latest one are superseded. The latest version eventually transitions to the Closed state, following case processing.

Add a Follow-Up Case describes how to create a new version of a Case.

Voided This state is for Cases that have completed the Void Case action. Some examples are Cases that were created by error or Cases for which companies no longer want to submit follow-up information.
Nullified This state is for Cases that have completed the Void Case action and have nullified previous Transmissions. This state is also for Cases that are found to be erroneous after being transmitted.
Invalid This state is for Cases that are found to be invalid after initial intake, for whatever reason. For example, Cases that are missing key criteria, such as patient or reporter data, or determined to be duplicate during case processing.
Rejected This state is for Cases that are rejected during intake. In this state, AERs are closed to prevent further processing or Case promotion. Reject an AER provides more information.

Active and Inactive States

The Active and Inactive states are standard vault object states added to all object lifecycles, associated with the Active and Inactive statuses. Objects in the Inactive state are not available for use. These states are not configured in the default Case Processing workflow.


Automated Case Promotion
About the Case Page
Feedback?