# Case Processing Overview

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 <a href="/en/gr/01252/">Reporting Rule Set</a>. Your Vault may also have <a href="/en/gr/01252/#override-rules">custom due date overrides</a> 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 <a href="/en/gr/01229/#inbox-item-and-case-actions">keyboard shortcuts</a>.


<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: When processing Cases that may be reportable to the PMDA, see <a href="/en/gr/696910/">Complete Intake and Process Cases for the PMDA</a> for regionally specific features in Veeva Safety.</p>
    </div>
  </div>
</div>



## Case States {#case-processing-lifecycle-stages}

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 {#intake}

The following table summarizes the intake states:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>New</em></td>
            <td>This state is for newly created <em>Cases</em>.</td>
        </tr>
        <tr>
            <td><em>Importing</em></td>
            <td>This state is for <em>Cases</em> that are being imported from an E2B file. In this state, Vault is in the process of extracting E2B data.</td>
        </tr>
        <tr>
            <td><em>Triage Required (Initial)</em></td>
            <td>This state is for initial <em>Cases</em> that are ready to be triaged.</td>
        </tr>
        <tr>
            <td><em>Triage Required (Follow-up)</em></td>
            <td>This state is for follow-up <em>Cases</em> that are ready to be triaged.</td>
        </tr>
        <tr>
            <td><em>In Triage</em></td>
            <td>This state is for <em>Cases</em> that are actively being triaged.</td>
        </tr>
        <tr>
            <td><em>Import Error</em></td>
            <td>This state is for <em>Cases</em> 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.</td>
        </tr>
    </tbody>
</table>

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:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>New</em></td>
            <td>When the <em>Case Lifecycle State Change Error Handling</em> feature is turned on in your Vault, initial <em>Cases</em> that encountered a lifecycle state change error remain in this state. When in this state, Vault populates the <a href="#lifecycle-state-change-error-handling"><em>System Alerts</em></a> field to inform you of the <em>Case</em> lifecycle state change error status.</td>
        </tr>
        <tr>
            <td><em>Entry</em></td>
            <td>This state is for <em>Cases</em> that are ready for users to <a href="/en/gr/917562/">perform data entry</a> and enter the full case details.</td>
        </tr>
        <tr>
            <td><em>Revision</em></td>
            <td>This state is for <em>Cases</em> that have entered the <em>Case</em> revision workflow to modify a previously approved <em>Case</em>. In this state, the <em>Case</em> is unlocked and available for users to <a href="/en/gr/01174/">revise or add information</a>.</td>
        </tr>
        <tr>
            <td><em>QC Required</em></td>
            <td>This state is for <em>Cases</em> that require a quality check.</td>
        </tr>
        <tr>
            <td><em>QC</em></td>
            <td>This state is for <em>Cases</em> that are actively being quality checked to <a href="/en/gr/01173/">review the <em>Case</em> data entry</a> and ensure complete and accurate information has been entered.</td>
        </tr>
    </tbody>
</table>

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: 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.</p>
    </div>
  </div>
</div>



#### 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_ <a href="/en/gr/44069/#list-page">record list</a>. 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 <a href="/en/gr/01152/#view-case-audit-trail">view the _Case_ audit trail</a> 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:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>Medical Review Required</em></td>
            <td>This state is for <em>Cases</em> that require medical review.</td>
        </tr>
        <tr>
            <td><em>Medical Review</em></td>
            <td>This state is for <em>Cases</em> that are actively <a href="/en/gr/01172/#case-assessments">being reviewed</a>. In this state, authorized users can perform the following tasks, as required:
                <ul>
                    <li><a href="/en/gr/01167/">Generate the narrative document</a>.</li>
                    <li>Assess and enter the causality assessment result for each linked adverse event and suspect product.</li>
                    <li>Assess and enter a single case diagnosis.</li>
                    <li>Ensure the case is entered correctly and enters or edits the expectedness and seriousness criteria.</li>
                </ul>
                <p>The <em>Medical Review</em> state also triggers <a href="#unblinding">case unblinding</a>, if required.</p>
                </td>
        </tr>
        <tr>
            <td><em>Correction Required</em></td>
            <td>This state is for <em>Cases</em> that require corrections.</td>
        </tr>
    </tbody>
</table>

### Unblinding {#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:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>Unblinding Required</em></td>
            <td>This state is for <em>Cases</em> that require unblinding.</td>
        </tr>
        <tr>
            <td><em>Unblinding</em></td>
            <td>This state is for <em>Cases</em> that have started the <a href="/en/gr/01176/"><em>Unblinding</em> workflow</a>. <em>Cases</em> remain in this state until an authorized user chooses to break the blind or maintain the blind.</td>
        </tr>
        <tr>
            <td><em>End of Study Unblinding</em></td>
            <td>This state is for follow-up <em>Cases</em> created by Vault during a <a href="/en/gr/01181/">bulk unblind operation</a>.</td>
        </tr>
        <tr>
            <td><em>Unblinded</em></td>
            <td>This state is for <em>Cases</em> that have been unblinded. Once a <em>Case</em> is unblinded, <a href="/en/gr/01176/">blind protection</a> continues to mask sensitive study information for unauthorized users.</td>
        </tr>
        <tr>
            <td><em>Recoded</em></td>
            <td>This state is for <em>Cases</em> on which MedDRA-coded terms have been recoded through the <a href="/en/gr/01183/">MedDRA Bulk Recode tool</a>.</td>
        </tr>
    </tbody>
</table>

If your Admin has configured your Vault to isolate blinded product information on Clinical Trial Study <em>Cases</em>, see <a href="/en/gr/691317/#study-product-lifecycle-states">Isolate Blinded Clinical Trial Information</a> for more information on unblinding states.


### Voiding {#voiding}

The following table summarizes the voiding states:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>Voiding Required</em></td>
            <td>This state is for <em>Cases</em> that require voiding.</td>
        </tr>
        <tr>
            <td><em>In Voiding Reason</em></td>
            <td>This state is for <em>Cases</em> that require voiding and enables users to enter the reason voiding is required.</td>
        </tr>
        <tr>
            <td><em>Voiding</em></td>
            <td>This state is for <em>Cases</em> that are actively being <a href="/en/gr/01259/#void-case">voided</a> after running the <em>Void Case</em> action.</td>
        </tr>
        <tr>
            <td><em>Nullifying</em></td>
            <td>This state is for <em>Cases</em> that are actively being nullified after initiating the <em>Void Case</em> action and also <a href="/en/gr/01259/#nullify-case">nullifying</a> previous <em>Transmissions</em>.</td>
        </tr>
    </tbody>
</table>

### Submission

The following table summarizes the submission states:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>Approval Required</em></td>
            <td>This state is for <em>Cases</em> that require approval.</td>
        </tr>
        <tr>
            <td><em>In Approval</em></td>
            <td>This state is for <em>Cases</em> that are actively being reviewed for approval.</td>
        </tr>
        <tr>
            <td><em>Approved</em></td>
            <td><p>This state is for <em>Cases</em> for which data entry and reviews are complete, and are <a href="/en/gr/01150/">ready for submission</a>.</p>
            <p>Once a <em>Case</em> enters the <em>Approved</em> state, Vault generates any <em>Submission</em> and <em>Distribution</em> records, depending on the <a href="/en/gr/01256/">reporting rules</a> configured in your Vault.</p>
            <p>The following pages provide more information on <em>Submissions</em> and <em>Distributions</em>:</p>
            <ul>
                <li><a href="/en/gr/01224/">Generate a Regulatory Report</a></li>
                <li><a href="/en/gr/01264/">ICSR Transmissions Overview</a></li>
            </ul>
            <p>Approved <em>Cases</em> are locked from further changes prior to submission. However, users can still make changes to the <em>Case</em> by initiating the <a href="/en/gr/01174/">Case Revision</a> workflow.</p>
            <p>Once the submission process is complete, authorized users can <a href="/en/gr/01161/">close the <em>Case</em></a>.</p>
            </td>
        </tr>
        <tr>
            <td><em>Transmission Error</em></td>
            <td>This state is for <em>Cases</em> for which a transmission error occurred during electronic gateway distributions. Once a <em>Case</em> enters this state, you cannot close the <em>Case</em> until you resolve the transmission errors.</td>
        </tr>
        <tr>
            <td><em>Validation Error</em></td>
            <td>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, <em>Transmissions</em> in <em>Validation Error</em> status can be excluded from submission or distribution.</td>
        </tr>
    </tbody>
</table>

### Complete

The following table summarizes the complete states:

<table>
    <thead>
        <tr>
            <th>Lifecycle State</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><em>Closed</em></td>
            <td>This state is for <em>Cases</em> that have been closed, and therefore locked from further changes. Once a <em>Case</em> enters this state, the only way to revise the <em>Case</em> is to create a new version. For more information, see <a href="/en/gr/01161/">Close a Case</a>.</td>
        </tr>
        <tr>
            <td><em>Superseded</em></td>
            <td>
                <p>This state is for <em>Cases</em> that are superseded by a newer version. When a <em>Case</em> has multiple versions, all versions except the latest one are superseded. The latest version eventually transitions to the Closed state, following <em>Case</em> processing. For more information on how to create a new version of a <em>Case</em>, see <a href="/en/gr/01148/">Add a Follow-Up Case</a>.</p>
                <p>We do not recommend changing any <em>Case</em> data when a <em>Case</em> is in <em>Superseded</em> state as it has already processed and is in its terminal state.</p>
            </td>
        </tr>
        <tr>
            <td><em>Voided</em></td>
            <td>This state is for <em>Cases</em> that have completed the <em>Void Case</em> action. Some examples are <em>Cases</em> that were created by error or <em>Cases</em> for which companies no longer want to submit follow-up information.</td>
        </tr>
        <tr>
            <td><em>Nullified</em></td>
            <td>This state is for <em>Cases</em> that have completed the <em>Void Case</em> action and have nullified previous <em>Transmissions</em>. This state is also for <em>Cases</em> that are found to be erroneous after being transmitted.</td>
        </tr>
    </tbody>
</table>

### 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.