Create action items on a Case to assign tasks to case processors, such as requests for follow-up information.
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 Import Study and Product Matching
Based on the Organization, Vault Safety matches E2B- or JSON-imported Cases to the relevant Studies and Products set up in the Business Admin > Objects library. Your Admin can configure confidence criteria to determine the threshold at which Vault performs Product matching. See the Company Product Match Verification section for more information.
Vault only looks at Studies and Products under the Organization set on the E2B document or JSON file.
The following flowchart summarizes how Vault performs Study and Product matching during import:
Study Matching
Vault matches Study and Study Registrations using one of the following two scenarios:
- Scenario 1: (E2B(R3) and JSON) If the E2B or JSON file contains at least one valid Study Registration, the study is matched using the registration number and country on Study Registrations.
- A Study Registration is valid for E2B(R3) when it contains both C.5.1.r.1 (Registration Number) and C.5.1.r.2 (Registration Country), with a valid country code. For JSON, a Study Registration must contain both
registration_number__vandcountry__vfields.
- A Study Registration is valid for E2B(R3) when it contains both C.5.1.r.1 (Registration Number) and C.5.1.r.2 (Registration Country), with a valid country code. For JSON, a Study Registration must contain both
- Scenario 2: (E2B(R2), (R3), and JSON) If there is no valid study registration in the E2B or JSON file, the study is matched using the Study Number. This is the only Study matching scenario available for E2B(R2) imports.
For E2B(R3) imports, if multiple Studies contain a matching Study Registration, Vault uses C.5.3 (Study Number) to find the correct Study. If C.5.3 does not match any Study, no match is found and the E2B notification logs a warning.
Note: There is no match if any E2B C.5.1.r.1 (Registration Number) or C.5.1.r.2 (Registration Country) conflict with the Registration Numbers and Countries listed on the Vault Safety Study record. In other words, the Vault Safety Study must contain all registrations contained in an E2B(R3) file.
The following table describes the matching logic and result for scenarios 1 and 2.
| Scenario | Matching | Result | ||||
|---|---|---|---|---|---|---|
| E2B(R3) | E2B(R2) | JSON | Vault Object | Vault Field | ||
| 1 | C.5.1.r.1 | N/A | registration_number__v |
Study > Study Registration | registration_number__v |
If both the Registration Number and Country match a Study Registration:
|
| C.5.1.r.2 | N/A | country__v |
Study > Study Registration | country__v |
||
| 2 | C.5.3 | A.2.3.2 | name__v |
Study | name__v |
|
Study Product Matching
The following prerequisites must be met to match Study Products:
- The Study must have been matched to a Vault Safety Study.
- The Product must not be blinded (G.k.2.5 or
blinded_protection__v). If blinded, the Product is imported as an External Product. - The drug role (G.k.1/B.4.k.1 or
drug_role__v) must be Suspect, Interacting, Drug Not Administered, or unspecified (null). If unspecified, the Drug Role is mapped to Suspect on import.
When the above prerequisites are met, Vault attempts to match the Study Product using the MPID, PHPID, Substance TermID, or Name. If there are multiple Study Product matches, the first Study Product match with a Drug Role of Suspect is assigned rank 1.
The following table describes the matching logic and result for scenarios 1 to 5:
| Scenario | Matching | Result | ||||
|---|---|---|---|---|---|---|
| E2B(R3) | E2B(R2) | JSON | Vault Object | Vault Field | ||
| 1 | G.k.2.1.1b | N/A | mpid__v |
Study Product > Product Registration | mpid__v |
If any scenario (1–5) matches:
|
| 2 | G.k.2.1.2b | N/A | phpid__v |
Study Product > Product Registration | phpid__v |
|
| 3 | G.k.2.3.r.2b | N/A | term_id__v |
Study Product > (all) Study Product Substances |
term_id__v |
|
| 4 | G.k.3.1 | B.4.k.4.1 | registration_number__v |
Study Product > Product Registration | registration_number__v |
|
| 5 | G.k.2.2 | N/A | name__v |
Study Product | name__v |
|
If none of the above scenarios match and if the Study is blinded, Vault attempts to match the Study Product using the Blinded Name (for example, “Placebo” instead of “Cholecap”).
If there is no Study match, Vault attempts non-Study Product matching. If there is no match to a non-Study Product, Vault attempts to match the reported Product using the Product Aliases and Substance Aliases library. You can add new aliases to a Product or Substance. If Vault can’t find a match using aliases, the Case Product is imported with the Case Product > Product Type (object_type__v) set to External Product.
Primary Product: The first imported Case Product with Drug Role=Suspect that’s matched to a Study Product is made the primary Case Product. If there are no Case Products with Drug Role=Suspect, the first imported Study Product is made primary.
Product Matching (Non-Study)
Vault attempts to match the Case Product to the Product library. The first Company Product match, if any, with a Drug Role of Suspect is assigned rank 1.
The following table describes the matching logic and result for scenarios 1 to 4:
| Scenario | Matching | Result | ||||
|---|---|---|---|---|---|---|
| E2B(R3) | E2B(R2) | JSON | Vault Object | Vault Field | ||
| 1 | G.k.2.1.1b | N/A | mpid__v |
Product > Product Registration | mpid__v |
If a scenario 1–3 matches:
|
| 2 | G.k.2.1.2b | N/A | phpid__v |
Product > Product Registration | phpid__v |
|
| 3 | G.k.3.1 | B.4.k.4.1 | registration_number_v |
Product > Product Registration | registration_number_v |
|
| 4 | G.k.2.2 | B.4.k.2.1 | name__v |
Product | name__v |
If only scenario 4 matches:
|
If none of the above scenarios match, Vault attempts to match the reported Product using the Product Aliases and Substance Aliases library. You can add new aliases to a Product or Substance.
If the Product is blinded:
- No Product or Product Registration matched.
- Case Product > Product Type > (
object_type__v) is set to External Product.
Primary Product: The first imported Case Product with Drug Role=Suspect that’s matched to a Product is made the primary Case Product. If there are no Case Products with Drug Role=Suspect, the first imported Case Product is made primary.
Product and Substance Alias Matching
You must have added Product Aliases and Substance Aliases to the library in order to use them to match the reported product.
Product Alias Matching
Vault attempts to match the reported Case Product to an alias from the Product Aliases list. If there is a match, the reported Case Product is linked to a Product in the library. If multiple Products in the library use the same Product Alias, Vault cannot match the imported product to a Product Alias.
If your Admin enabled additional matching fields for Product Aliases, in the scenario where multiple library Products have the same Product Alias name, Vault looks at additional Inbox Item Product fields to determine which Product in the library is a better match. For more information on this additional field matching, see Manage Products in Vault Safety.
If Vault cannot match the imported product to a library Product using additional field matching, either because no fields match or there is more than one (1) match, Vault selects the library Product Alias using the Default Alias field. In other words, Vault auto-codes the imported product to the library Product Alias that is set as the Default Alias. If multiple Default Aliases are configured, Vault codes the Product Alias with the latest modified date. If there is no Default Alias configured, Vault does not return a match.
If Vault cannot find a match using the Product Alias list, Vault attempts to match the reported Product Substance to an alias from the Substance Aliases list. If there is a match, the reported Product Substance is linked to the associated Product of the Substance Alias.
Substance Alias Matching
There must be an absolute match for Vault to match the reported Case Product to a Product in the library. The following diagram illustrates an example of an absolute match and a non-absolute match:
- If there are multiple reported substances that match one product in the Library, Vault still links the reported Case Product to the respective Product in the library, in this scenario, Cholecap.
- If the reported substances match to different products in the Library, Vault does not find a product match. In this scenario, the reported Case Product does not match to either DrugX or Cholecap. Similarly, if one reported substance matches multiple products in the Library, Vault can not find an associated product match for the reported substance.
If Vault cannot find any matches for the reported Product, Vault imports it with the Case Product > Product Type (object_type__v) set to External Product.
When your Admin updates or creates a new Product Registration, Vault adds the Registration Name (Trade Name) as a new Product Alias, if it does not already exist.
Study Product Blinded Name Matching
The following flowchart summarizes how Vault performs Blinded Name (Study Product Placeholder) matching for an E2B or JSON with blinded Studies:
For E2B(R3) or JSON files containing a blinded Study, Vault first attempts to match the Blinded Name (Study Product Placeholder) on the Study Product. If a match is found, the Blinded Name of this Study Product becomes the primary Product on the Inbox Item (assigned rank 1).
If there is more than one Study Product, Vault attempts to match the Blinded Name for each. The first match becomes the primary Product.
If no match is found or if the Blinded Name is blank, Vault attempts to match the Study Product, followed by the Company Product, and then the aliases.
Company Product Match Verification
Your Admin can configure advanced Company Product Match Verification to consider additional criteria when auto-coding Company Products upon import to Inbox Item. Based on matching criteria, Vault provides a confidence assessment for you to review. This also includes the ability to override the auto-coding if the confidence criteria are not met.
For example, if the Auto code min Product Confidence level set on the Intake Settings page is 2 - Confident Match and Vault determines the Inbox Item’s Product Match Confidence to be 2 - Confident Match or 1 - Exact Match, the auto-code will remain.
However, if the Inbox Item’s Product Match Confidence falls below 2-Confident Match, Vault leaves the Company Product field blank.
The Product Match Criteria displays the Product Coding criteria set by your Admin.
See the following resources for more information:
- Inbox Item Field Reference: Product Match Confidence and Product Match Criteria fields
- Configure Product Match Coding Verification: Must Match and Should Match Confidence Outcomes
- Configure Product Match Coding Verification: Product Match Coding Verification Diagrams