When you promote a record to a Case, Vault runs duplicate detection to find potential matches and prevent duplicate Cases.
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 Case, you can promote an existing Inbox Item using the Promote to Case action.
When you initiate the Case promotion process, Vault duplicate detection compares the current record against all other Cases and Inbox Items in Vault. 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 (1) 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 Vault 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.
If your Admin has configured your Vault to isolate blinded Product information on Clinical Trial Study Cases, see Promoting Inbox Items for Clinical Trial Cases for additional considerations about Case promotion.
Prerequisites
The following list outlines the prerequisites for promoting an Inbox Item to a Case:
- 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 (1) of the following:
- Country of the Primary Reporter
- Country of the Primary Adverse Event
- Adverse Event
- One (1) of the following:
- Study
- Company Product
Valid Case Criteria
An Inbox Item should have enough information to qualify as a valid Case before you promote to Case.
There are fields on the Inbox Item objects to help you check whether a record has the required information to qualify as a valid Case.
The following image displays these fields, which are automatically populated based on the data entered on the record:
Promote an Inbox Item to a Case
Once you’ve verified that an Inbox Item has all the data required for a valid ICSR, you can access the Promote to Case action from the All Actions menu on the record or by selecting 
.
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 creates the Case and an Inbound Transmission record.
Note: Your Admin can configure your Vault to display 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.
Duplicate Detection
During duplicate detection, Vault compares the current record against all other Cases and Inbox Items in Vault to find potential matches and prevent duplicates. You’ll see the following screen while Vault performs duplicate detection:
Vault 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 Vault detects matching information, the Potential Matches page appears.
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.
Only potential matches from the last two (2) years are returned. In other words, potential matches with a New Info Date value within the last two (2) years of the current day.
The following table describes the indicators that assist with comparing information:
| Indicator | Description |
|---|---|
 |
The values are the same between the records. |
 |
The values are similar between the records. For the Event Onset date, this indicator appears when the date values differ by up to 30 days. |
Additional Duplicate Detection Capabilities
Your Admin can configure the following capabilities to be used alongside duplicate detection:
- Index Migrated Cases for Search
For Cases migrated after 23R1, your Admin must select the Index Migrated Cases checkbox for Vault 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, Vault clears the Index Migrated Cases checkbox. If more Cases are migrated into Vault, your Admin can select the checkbox again to index them.
If any migrated Cases were unable to be indexed (for example, due to errors), Vault 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. - 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:
For more information about PHI and PII encryption and the fields that are encrypted by default, see Manage Field Encryption.
How Duplicate Detection Works
Vault looks at certain data points on each Case to determine potential matches.
Duplicate detection considers many field values when searching for potential matches. As long as there is one (1) field match, the Case or Inbox Item will be returned as a potential match.
Duplicate detection 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.
Vault 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, Vault cannot compare the Study Product with other Cases.
Types of Potential Matches
Duplicate detection provides an extensive list of potential matches by considering many field values in the search. With this search, records with sparse information can be considered a match.
Duplicate detection can be used to determine whether each potential match is a likely match or a possible match:
A search result is tagged with 
when there is an ID match. For example:
- UID, WWUID, External UID, Case Identifiers
- Link (this field supports matching for Inbox Items received from the Safety-EDC Vault Connection)
Note: A cross-compare match between identification fields (for example, a WWUID matching an External UID) also results in a likely match.
A search result is tagged with 
if any field value matches.
Potential match results are ranked in the following order:
| Rank | Matching Record | Fields |
|---|---|---|
| 1 | Patient | Initials, DoB, MRN, Sex, First Name, Last Name |
| 2 | Study | Study Number |
| 2 | Primary Reporter1 | First Name, Last Name, Qualification |
| 3 | Case Product | Reported Product Name, Company Product |
| 4 | Adverse Event2 | Reported Event Name, MedDRA PT term |
1. A primary reporter can contribute to a possible match if the first and last names are switched between records, for example, Jacob Smith and Smith Jacob.
|
||
2. A reported or coded Adverse Event can contribute to a possible match if it is partially matching, for example, Heart Attack and Panic Attack.
|
||
In the scenario where potential match A matches on Patient and potential match B matches on Study, Primary Reporter, and Case Product, Vault still ranks potential match A first.
If more than one (1) potential match has the same matching record type (for example, there are two (2) potential matches with Patient matches), Vault ranks the one with more field matches higher.
Complete the Potential Matches Page
The following images illustrate the Potential Matches page when comparing the current record to a Case and Inbox Item, respectively:
- In the left pane, select a Case or Inbox Item to compare it with the current record.
- Proceed with one (1) of the following:
- If you selected a Case, review the details listed in the comparison table to determine whether the current record is a new Case, 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.
- Select one (1) 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 appears when you are comparing a Case to your current record. Vault directs you to the Inbox Item to Case Compare page. Based on the lifecycle state of the matched Case, you can perform additional actions on this page such as:
The Mark as Follow-Up and Merge to Current actions are not available for matched Cases in the Void, Nullified, Voiding, or Nullifying state or in any state with the Deleted state type. See Complete the Inbox Item to Case Compare Page for more detail. |
| 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, Vault 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, Vault creates an initial Case and an Inbound Transmission record. |
A link to the matching record is also provided under the Likely Match or Possible Match heading. Select the link to access the matching record for more information.
Excluded Case States
Vault compares the current Inbox Item with all Cases and Inbox Items linked to the same Organization, except those in the following states:
| Excluded State | Description |
|---|---|
| Superseded Cases | Vault looks at the latest Case version rather than Superseded versions. |
| Promoted Inbox Items | Vault looks at the promoted Case rather than the original Inbox Item. |
| Duplicate Inbox Items | Vault does not look at Duplicate Inbox Items because they cannot be promoted to Cases. |
| Rejected Inbox Items | Vault does not look at Rejected Inbox Items because they cannot be promoted to Cases. |
Considerations When Promoting a Blinded Study Case Inbox Item
For Blinded Study Case Inbox Items with no Study Arms, Vault uses the following logic upon Case promotion:
- If the Study Product role is set to Standard of Care, Vault ignores the Inbox Item Study Product Blinded field as Standard of Care Products are always considered Open Label.
- If the Study Product role is set to any other value, Vault copies the Study Product name to the Blinded Name field on the Case. Vault 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 |
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 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 Inbox Item to 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.