Promote to Case

When you promote a record to a Case, the system runs duplicate detection to find potential matches and prevent duplicate Cases.

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 Promotion

To create a new Vault Safety Case, you can promote an existing AER or Inbox Item using the Promote to Case action.

When you initiate the Case promotion process, Vault Safety duplicate detection compares the current record against all other Cases in the system. The check is useful in the following scenarios:

  • Preventing duplicate Case creation
  • Creating follow-up Cases
  • Copying patient information to a new Case

Note Once a Case has been created with at least one Case Adverse Event, Case Product, or Case Reporter, you cannot delete the Case record from your vault. Furthermore, you cannot delete the following primary Case child records, which the system automatically creates upon Case promotion:

  • Primary Case Adverse Event
  • Primary Case Reporter
  • Primary Case Product

Another Case promotion method is available for Inbox Items received through an AS2 gateway Transmission, Intake API, or created from an E2B file. See Automated Case Promotion for more detail.

Prerequisites

The following checklists outline the prerequisites for promoting an Inbox Item or AER to a Case.

Inbox Item Promotion Prerequisites

  • The Organization must be specified on the Inbox Item.
    The Organization is required to ensure only users with permissions in that Organization can view the Inbox Item and the resulting Case.
  • Your vault may be configured to hide the Promote to Case action until the Inbox Item is in the Verified state.
  • Your vault may be configured to hide the Promote to Case action until the following minimum case criteria fields are set:
    • Identifiable Patient
    • Identifiable Reporter
    • One of the following:
      1. Country of the Primary Reporter
      2. Country of the Primary Adverse Event
    • Adverse Event
    • One of the following:
      1. Study
      2. Company Product

AER Promotion Prerequisites

  • The Organization must be specified on the AER.
    The Organization is required to ensure only users with permissions in that Organization can view the AER and the resulting Case.
  • The following minimum case criteria fields must be set to Yes:
    • Identifiable Reported Event
    • Identifiable Patient
    • Identifiable Reporter
    • Identifiable Country
    • Identifiable Company Product

Valid Case Criteria

An AER or Inbox Item should have enough information to qualify as a valid case before you promote to Case.

There are fields on the AER and Inbox Item objects to help you check whether a record has the required information to qualify as a valid case.

The following images show these fields, which are automatically populated based on the data entered on the record:

  • Note For AERs, an Administrator can configure your environment to require additional custom valid case criteria using Vault formulas.

    AER Case Validity Fields
    AER Case Validity Fields
  • Inbox Item Case Validity Fields
    Inbox Item Case Validity Fields

Promote an Inbox Item or AER to a Case

Once you’ve verified that an AER or Inbox Item has all the data required for a valid ICSR, you can access the Promote to Case action from the All Actions (All Actions) menu on the record or by selecting Create Case Action.

Once you initiate the Promote to Case action, duplicate detection runs automatically.

If any information in the record matches an existing Case, the Potential Matches page appears.

If the record does not match any existing Cases, Vault Safety creates the Case and an Inbound Transmission record.

Note Your Administrator can configure your vault to display user actions to promote Inbox Items at any given lifecycle state. For example, a configuration might only allow you to promote the Inbox Item after completing the verification process, or it may allow you to promote when the Inbox Item is still in the Triage state. Refer to your standard operating procedures for more information.

Learn how Case intake and Case promotion consider Inbox Items with Combination Products.

Overview of Duplicate Detection

During duplicate detection, Vault Safety compares the current record against all other Cases and AERs or Inbox Items in the system to find potential matches and prevent duplicates. You’ll see the following screen while the system performs duplicate detection:

Running Duplicate Detection
Running Duplicate Detection

The system matches across Report Types, but filters based on Study Type so that Clinical Trial Study Cases are matched only to other Cases with the Clinical Trial Study Type. If the system detects matching information, the Potential Matches page appears.

Potential Match Page
Basic Duplicate Detection Potential Matches Page

The left pane lists all potential match Cases with similar or matching information. The returned results are ranked from the most similar (top) to least similar (bottom) match. The Comparison table lists the information for the current record side-by-side with the Case that is a potential match.

The following indicators assist with comparing information:

  • Potential Match represents an exact match.
  • Potential Match represents a partial match or similar information.

Only potential matches from the last two years are returned. In other words, potential matches with a New Info Date value within the last two years of the current day.

The following table provides an overview and comparison of the duplicate search options and functionality.

BASIC DUPLICATE DETECTION (Default) DEEP DUPLICATE DETECTION
Search Criteria Considers:
  • UIDs (UID, WWUID, External System UID, Case Identifiers)
  • Primary Product
  • Primary Event
  • Primary Reporter
  • Patient
Considers:
  • UIDs (UID, WWUID, External System UID, Case Identifiers)
  • Primary and non-primary Product and Event
  • Primary Reporter
  • Patient
  • Partial matching, meaning any field matches result in a potential match.

Less strict likely and possible match tagging criteria, which provides more matching results.

Promotion Supported for AER and Inbox Item promotion. Supported for Inbox Item promotion but not supported for AER promotion.
Records Included in Search Considers AERs and Cases in search. Considers Inbox Items (configurable in Duplicate Search Options), AERs, and Cases.
Ranking Potential match results are ranked from most similar to least. Potential match results are ranked using matching:
  1. Patient
  2. Reporter
  3. Product
  4. Event
Duplicate Actions (New Case, Copy Patient Info, Duplicate, Follow-Up, Mark as Follow-Up) Available on the Potential Matches page. Available on the Inbox Item to Case Compare page.

The deep duplicate detection option is enabled by default for all Vaults for Inbox Item promotion. Since this duplicate detection option does not support AER promotion, the system defaults to basic duplicate detection functionality when promoting an AER to a Case.

Deep duplicate detection uses partial matching and considers more field values in the search than basic duplicate detection, providing more potential match results.

Two capabilities were introduced in 23R1 for both basic and deep duplicate detection.

  1. Index Migrated Cases for Search

    For Cases migrated after 23R1, your Admin must select the Index Migrated Cases checkbox for the system to consider these Cases on the Potential Matches page. Imported Cases are no longer indexed during migration for duplicate detection by default.

    Once the migrated Cases are successfully indexed for duplicate detection, the system clears the Index Migrated Cases checkbox. If more Cases are migrated into the system, your Admin can select the checkbox again to index them.

    If any migrated Cases were unable to be indexed (for example, due to errors), the system leaves the checkbox enabled. Contact Veeva Support for assistance.

    The indexing speed is around 50,000 Cases per hour but may vary depending on the data and load.

  2. Mask PHI and PII Information on the Potential Matches Page

    Your Admin must enable PHI and PII masking on the Potential Matches page to use this feature. Once your Admin enables this checkbox, PHI and PII field information resembles the following:

    phi-pii-masked-value
    Masked PHI/PII Field Values on the Potential Matches Page

    For more information about PHI and PII encryption and the fields that are encrypted by default, see Manage Field Encryption.

(Default) Deep Duplicate Detection

This is the default duplicate detection option for all Vaults. The Duplicate Search Options, which are required to use this feature, are automatically enabled. Note that since this duplicate detection option is not supported for AER promotion, the system uses basic duplicate detection when you are promoting an AER to a Case.

Note Deep duplicate detection only returns Inbox Items and Cases as potential matches and not AERs.

Deep duplicate detection considers more field values than basic duplicate detection in the search. This search option provides a more extensive list of potential matches as records with sparse information can be considered a match.

Deep duplicate search can be used to determine whether each potential match is a likely match or a possible match:

A search result is tagged with likely-match-tag when there is an ID match. For example:

  • UID, WWUID, External UID, Case Identifiers
  • Patient MRN, Investigation MRN, Specialist MRN, Hospital MRN, GP MRN

Note A cross-compare match between identification fields (for example, a WWUID matching an External UID) or a cross-compare match between an MRN field (for example, Patient MRN with Investigation MRN) also results in a likely match. This cross-comparison only occurs when deep duplicate detection is enabled.

A search result is tagged with possible-match-tag if any field value matches. Potential match results are ranked in the following order:

Rank Matching Record Fields
1 Patient Initials, DoB, MRN, Gender
2 Study Study Number
2 Primary Reporter First Name, Last Name, Qualification
3 Case Product Reported Product Name, Company Product
4 Adverse Event Reported Event Name, MedDRA PT

In the scenario where potential match A matches on Patient and potential match B matches on Study, Primary Reporter, and Case Product, the system still ranks potential match A first.

If more than one potential match has matched within a category (for example, there are two potential matches with Patient matches), the system ranks the one with more field matches higher.

You can also compare open Inbox Items to your current record on the Potential Matches page. This is a deep duplicate search capability.

  • How Deep Duplicate Detection Works
    The system looks at certain data points on each Case to determine potential matches.

    The deep duplicate search considers many field values when searching for potential matches. As long as there is one field match, the Case or Inbox Item will be returned as a potential match. Note that AERs are not considered in this option.

    Deep duplicate search also uses certain data points to exclude potential matches. The following potential matches are excluded:

    • Potential matches with a different Organization than the promoted Inbox Item.
    • Potential matches with a New Info Date value older than two years.
    • When the Study Type differs between the potential match and the promoted Inbox Item, specifically when one Study Type is set to Clinical Trial and the other Study Type is not.
    • Potential matches with a different Reporter Country than the promoted Inbox Item, unless any Patient fields match.

The system compares any Inbox Item UID (WWUID, UID, External System UID and Case Identifiers) with any Case UID (WWUID, UID, External System UID and Case Identifiers).

Note When a study Case is blinded, the system cannot compare the Study Product with other Cases.

Complete the Potential Matches Page for Deep Duplicate Detection

The Potential Matches page for deep duplicate detection contains different actions than for basic duplicate detection.

The following images illustrate the Potential Matches page when comparing the current record to a Case and Inbox Item, respectively.

potential-matches-page-v3-case
Potential Matches Page for Deep Duplicate Detection: Compare to Case
potential-matches-page-v3-inbox-item
Potential Matches Page for Deep Duplicate Detection: Compare to Inbox Item
  1. In the left pane, select a Case or Inbox Item to compare it with the current record.
  2. If you selected a Case, review the details listed in the comparison table to determine whether the current record is a new Case, or a new Case with existing patient details, a duplicate of an existing Case, or a follow-up Case.
    If you selected an Inbox Item, you can choose to create a new Case or mark the current record as a duplicate.
  3. Select one of the following options after reviewing the details:
    Option Description
    Cancel Select this option to exit the Potential Matches page and be redirected back to the current Inbox Item record.
    Compare Details This button is displayed when you are comparing a Case to your current record. The system directs you to the Inbox Item to Case Compare page. You can perform additional actions on this page such as:
    • Mark as a duplicate
    • Create a new Case with existing Patient information
    • Mark as Follow-Up
    • Merge to Current
    See Complete the Inbox Item to Case Compare Page for more detail.

    Note Note This option is not available for Inbox Items that are found to match a Case in the Void, Nullified, Voiding, or Nullifying lifecycle state or a Case in the lifecycle state with the Deleted state type. The Deleted state type can only be mapped to one lifecycle state.

    Mark as Duplicate This button is displayed when you are comparing an Inbox Item to your current record.
    Select this option if an Inbox Item is an exact match to the current record. If you select this option, the system marks the record as Duplicate and does not create a Case.
    Create New Case Select this option if the current record is not a duplicate of any potential matches.
    If you select this option, the system creates the Case and an Inbound Transmission record.

A link to the matching record is also provided under the Likely Match or Possible Match heading. You can select the link to access the matching record for more information.

Basic Duplicate Case Detection

By default, Vaults use Deep Duplicate Detection.

After triggering the Promote to Case action for the Inbox Item or AER, review and complete the Potential Matches page to continue.

  • How Basic Duplicate Detection Works: Fields
    The system looks at certain data points on each Case to determine potential matches.

    When searching for duplicate Cases, the system compares information entered or received in the following fields:

    Primary Product

    The system compares values entered in the following fields for the primary Case Product:

    • Product
    • Study
    • Study Product
    • Study Arm

    Note When a Study Case is blinded, the system cannot compare the Study Product with other Cases.

    Primary Events

    The system compares values entered in the following fields for the primary Case Adverse Event:

    • Event Country
    • Event (Reported)
    • Event (MedDRA)
    • Event Onset

    Patient

    The system compares values entered in the following Case Patient fields:

    • Patient Initials/ID
    • Gender
    • Date of Birth
    • Age at Onset
    • Gestation
    • Age Group
    • GP MRN
    • Hospital MRN
    • Investigation MRN
    • Specialist MRN

    Primary Reporter

    The system compares values entered in the following fields for the primary Reporter Case Contact:

    • Reporter First Name
    • Reporter Last Name
    • Reporter Country
    • Reporter Qualification

    Note When a study Case is blinded, the system cannot compare the Study Product with other Cases.

    Receipt Date

    The system compares Receipt Dates between the Inbox Item and the potential match using the logic in the following table:

    Receipt Date Potential Match Tag
    Inbox Item Receipt Date is after the potential match Receipt Date and there is an ID match.
    • Search Result: Possible Follow-Up
    • Current Case: Possible Original
    Inbox Item Receipt Date is after the potential match Receipt Date, but there is no ID match.
    • Search Result: Possible Original
    • Current Case: Possible Duplicate
    Inbox Item Receipt Date is before the potential match Receipt Date.
    • Search Result: Possible Duplicate
    • Current Case: Possible Original

Complete the Potential Matches Page for Basic Duplicate Detection

potential-match-page
Basic Duplicate Detection Potential Matches Page
  1. In the left pane, select a Case to compare it with the current record.
  2. Review each Case listed in the Comparison table to determine whether the record is a new Case, a new Case with existing patient details, a duplicate of an existing Case, or a follow-up Case.
  3. From the drop-down list beside Possible Duplicate, select from the following options:
    Option Description
    New Case Select this option if the current record is not a duplicate of any potential matches.
    If you select this option, the system creates the Case and an Inbound Transmission record.
    New Case - Copy Patient Info If the current Inbox Item includes a patient with an existing Case, select the Case, and then select New Case - Copy Patient Info.
    If you select this option, in addition to creating a Case that includes the patient details, you can specify other information to copy, including the following:
    • Medical History
    • Drug History
    • Case Contacts
    • Test Results
    • Suspect/Interacting/Drug Not Administered Products
    • Concomitant Products
    • Narrative
    • Adverse Events to Medical History
    • Concomitant Products to Drug History

    See Copy Patient Information from Existing Case for more detail.

    Note The new Case is not linked to the original Case. However, the audit trail records which information was copied.

    Duplicate If a Case is an exact match to the current record, select the Case, and then select Duplicate.
    If you select this option, the system marks the record as Duplicate and does not create a Case. The system links the duplicate record to the matching Case in the Initial Case field.
    Follow-Up If an AER or Inbox Item is a follow-up to an existing Case, select the Case, and then select Follow-Up.
    If you select this option on an Inbox Item, the system directs you to the Case Compare page. See Inbox Item Follow-Up for more detail.
    If you select this option, the system promotes the AER to a Follow-Up Case. For more information, see Considerations for Follow-Up Promotion on an AER.

    Note This option is not available for Inbox Items that are found to match a Case in the Void, Nullified, Voiding, or Nullifying lifecycle state or a Case in the lifecycle state with the Deleted state type. The Deleted state type can only be mapped to one lifecycle state.

    Mark as Follow-Up Select this option to link the Inbox Item to an In-Flight Case An open Case that has not completed case processing (generally in any state before Approved, Closed, or Superseded). and indicate it should be merged with the Case. In order for the action to be successful, the Case must not have completed processing and can not be in a prohibited state.

    If you select this option, the state changes to Marked as Follow-up and a new section, Inbox Item has been marked as a follow-up, appears on the Inbox Item with a link to the associated Case. Note that an administrator must configure the Inbox Item page layout in order for this section to appear. This lets the Case Processor know there is new information on the Inbox Item that should be merged with the In-Flight Case.

    If you do not see this option, an administrator must enable the Mark as Follow-up option in the Case Promotion settings.

    You can undo this action by navigating back to the Inbox Item and selecting Unmark Follow-Up in the All Actions (All Actions) menu.

    Note Promoted Inbox Items cannot be unlinked from the Case.

  4. Select Complete.

Excluded Case States

Vault Safety compares the current Inbox Item or AER with all Cases and Inbox Items or AERs linked to the same Organization, except those in the following states:

Excluded State Description
Superseded Cases The system looks at the latest Case version rather than Superseded versions.
Promoted Inbox Items or AERs The system looks at the promoted Case rather than the original Inbox Item or AER.
Duplicate Inbox Items or AERs The system does not look at Duplicate Inbox Items or AERs because they cannot be promoted to Cases.
Rejected Inbox Items or AERs The system does not look at Rejected Inbox Items or AERs because they cannot be promoted to Cases.

Note AERs are not included in duplicate search, unless your vault uses basic duplicate detection.

Considerations When Promoting a Blinded Study Case Inbox Item

For Blinded Study Case Inbox Items with no Study Arms, the system uses the following logic upon Case promotion:

  1. If the Study Product role is set to Standard of Care, the system ignores the Inbox Item Study Product Blinded field as Standard of Care Products are always considered Open Label.
  2. If the Study Product role is set to any other value, the system copies the Study Product name to the Blinded Name field on the Case. The system also looks at the masking state of the Study Product and maps the blindedness value:
    INBOX ITEM STUDY PRODUCT BLINDED CASE PRODUCT MASKING
    Blinded Blinded
    Unblinded Unblinded
    Open Label Open Label
  3. Note The values that appear in the Case Product Masking fields depend on your Admin’s configuration. Values are mapped as follows:

    • Blinded = Yes
    • Unblinded = No
    • Open Label = blank
    .

For initial Cases, the Study Arm or Study Blinded setting on the Inbox Item is carried to the new Case. For Follow-up Cases created through the Create Follow Up Case user action on Study Cases, the Study Arm or Study Blinded setting is inherited from the original Study Case.

When creating a Follow-up Case or merging to an In-flight Case through the Case Compare page, Blinded values from Study Arms or Study Case Products are carried through the promotion. If the blinding needs to be changed on the Follow-up or merged Case, do this after Case promotion.

Considerations When Promoting an AER to a Follow-Up Case

The following sections describe important information to consider when you promote an AER to a Follow-Up Case, depending on how you created the follow-up AER. This section does not apply to Inbox Items.

For information on creating a Follow-Up Case from an initial Case in the Closed state, see Add a Follow-Up Case.

Promote an E2B Imported AER to a Follow-Up Case

When you promote a Follow-Up Case from an E2B-imported AER, the resulting Follow-Up Case contains only data from the E2B source file.

You must update the Follow-Up Case to add any information from the previous Case version that the E2B source file omits.

Promote a Manually Entered AER to a Follow-Up Case

When you promote a Follow-Up Case from an AER created through manual data entry, the resulting Follow-Up Case contains all data from the initial case and any additional information from the follow-up AER. You may need to correct duplicate information in the resulting Follow-Up Case.

When the Follow-Up AER contains conflicting data from the initial Case, the system reconciles certain information during case promotion.

The following list describes how Vault Safety reconciles certain fields when you promote an AER to a Follow-Up Case:

  • Masked Fields: For fields with a Reason Omitted masking option, the information entered in the AER being promoted to a Follow-Up takes precedence. For example, if the initial Case specified a field value, but the follow-up masked the same field with a Reason Omitted option, the resulting Follow-Up Case blanks the field but maintains the Reason Omitted option.
  • Value and Unit Fields: For the following fields, the latest data in the follow-up overwrites the value from the initial case, including null values:
    • Age
    • Gestation
    • Height
    • Weight
  • Age-Related Fields: The follow-up information takes precedence over the initial case for all age-related fields, including Date of Birth, Age at Onset, and Age Group.
  • Receipt Date: The receipt date remains constant across both the initial and follow-up case versions. The follow-up receipt date is recorded in the New Info Date field.

Request Additional Information
Promote to Multiple Cases
Feedback?