Vault calculates and assigns the regulatory reporting due date for Cases. The due date is based on the New Info Date on the Case, 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.
Vault calculates due dates 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 manually trigger due date calculation using the Recalculate Due Date user action from the All Actions menu on the Case or by using keyboard shortcuts.
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 Veeva Safety.
Case States
Each Case processing lifecycle stage is made up of one (1) 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 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 is in the process of extracting E2B data. |
| Triage Required (Initial) | This state is for initial Cases that are ready to be triaged. |
| Triage Required (Follow-up) | This state is for follow-up Cases that are ready to be triaged. |
| In Triage | This state is for Cases that are actively being triaged. |
| Import 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 uses the seriousness to calculate the Case priority and reporting due date.
Entry
The following table summarizes the entry states:
| Lifecycle State | Description |
|---|---|
| New | When the Case Lifecycle State Change Error Handling feature is turned on in your Vault, initial Cases that encountered a lifecycle state change error remain in this state. When in this state, Vault populates the System Alerts field to inform you of the Case lifecycle state change error status. |
| Entry | This state is for Cases that are ready for users to perform data entry and enter the full case details. |
| 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. |
| QC Required | This state is for Cases that require a quality check. |
| QC | This state is for Cases that are actively being quality checked to review the Case data entry and ensure complete and accurate information has been entered. |
Note: If you enter a partial date (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 to update the field.
Lifecycle State Change Error Handling
When the Case Lifecycle State Change Error Handling feature is turned on in your Vault, the System Alerts field appears in the Case record list. Vault populates this field with the State Change Failure value when the initial Case remains in the New lifecycle state due to a lifecycle state change error. When the Case successfully moves to another lifecycle state, Vault clears this field. You can view the Case audit trail for more information about the lifecycle state change error. Contact your Veeva Representative to turn this feature on in your Vault.
Review
In 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 Review Required | This state is for Cases that require medical review. |
| Medical Review | This state is for Cases that are actively being reviewed. In this state, authorized users can perform the following tasks, as required:
The Medical Review state also triggers case unblinding, if required. |
| Correction Required | This state is for Cases that require corrections. |
Unblinding
If a Case requires unblinding prior to medical review, it triggers 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 Required | This state is for Cases that require unblinding. |
| Unblinding | This state is for Cases that have started the Unblinding workflow. Cases remain in this state until an authorized user chooses to break the blind or maintain the blind. |
| End of Study Unblinding | This state is for follow-up Cases created by Vault during a bulk unblind operation. |
| 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. |
| Recoded | This state is for Cases on which MedDRA-coded terms have been recoded through the MedDRA Bulk Recode tool. |
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 Required | This state is for Cases that require voiding. |
| In Voiding Reason | This state is for Cases that require voiding and enables users to enter the reason voiding is required. |
| Voiding | This state is for Cases that are actively being voided after running the Void Case action. |
| Nullifying | This state is for Cases that are actively being nullified after initiating the Void Case action and also nullifying previous Transmissions. |
Submission
The following table summarizes the submission states:
| Lifecycle State | Description |
|---|---|
| Approval Required | This state is for Cases that require approval. |
| In Approval | This state is for Cases that are actively being reviewed for approval. |
| Approved | This state is for Cases for which data entry and reviews are complete, and are ready for submission. 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 Submissions 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 a 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 or 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. |
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.