Learn about the stages and states in the Vault Safety Case Processing lifecycle.
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 Rule Set. 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 menu on the Case.
Note: When processing Cases that may be reportable to the PMDA, see Complete Intake and Process Cases for the PMDA for regionally specific features in Vault Safety.
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:
Intake
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 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. For more information, see Complete Case Triage.
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. For more information, see Enter Case Data. |
| 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. For more information, see Revise an Approved Case. |
| 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. For more information, see Review Case Data Entry. |
Note: Due to default system behavior 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.
This state is not included in the default Case Processing workflow. If your organization requires this state, an Admin 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:
For more information, see Perform Medical Review. 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. For more information, see Manage Case Blinding. |
| End of Study Unblinding | This state is for Follow-up Cases created by Vault during a bulk unblind operation. For more information, see Bulk Unblind a Study. |
| 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. For more information, see Manage Case Blinding. |
If your Admin has configured your Vault to isolate blinded Product information on Clinical Trial Study Cases, see Isolate Blinded Clinical Trial Information for more information on unblinding states.
Voiding
The following table summarizes the Voiding states:
| Lifecycle State | Description |
|---|---|
| Voiding | This state is for Cases that are in the process of being voided after initiating the Void Case action. For more information, see Void a Case. |
| 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. For more information, see Void a Case. |
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. For more information, see Approve a Case. Once a Case enters the Approved state, Vault 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. For more information, see Close a Case. |
| 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. For more information on how to create a new version of a Case, see Add a Follow-Up Case. We do not recommend changing any Case data when a Case is in Superseded state as it has already processed and is in its terminal state. |
| 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, Inbox Items are closed to prevent further processing or Case promotion. |
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.