Sections in This Article
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 the system performs Product matching. See the Company Product Match Verification section for more information.
The system only looks at Studies and Products under the Organization set on the E2B document or JSON file.
The following flowchart summarizes how the system performs Study and Product matching during import:
Study Matching
Note For AERs, the E2B Report Type (C.1.3 / A.1.4) must be Study to import study information and attempt study matching. This restriction does not apply to Inbox Item E2B import.
The system 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. - 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.
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 |
|
For E2B(R3) imports, if multiple Studies contain a matching Study Registration, the system 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.
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, the system attempts to match the Study Product using the MPID, PHPID, Substance TermID, or Name.
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, the system looks at whether the Study contains Study Arms.
If there are no Study Arms, the system attempts non-Study Product matching. If there is no match to a non-Study Product, the system 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 system 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.
If there are Study Arm(s), the system checks whether any Blinded Names (Study Product Placeholders) have been populated and attempts to match them. If there is a match, the Study Arm Product becomes the Primary Product on the Inbox Item (assigned rank 1). If there are no Blinded Names or no match was found, then the system attempts matching using Product and Substance Aliases.
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)
The system attempts to match the Case Product to the Product library.
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, the system 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 and Substance aliases to the library in order to use them to match the reported Product.
The system 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 Case Product in the library.
If the system cannot find a match using the Product Aliases list, the system 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.
There must be an absolute match for the system 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, the system 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, the system 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, the system can not find an associated product match for the reported substance.
If the system cannot find any matches for the reported Product, the system 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, the system 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 the system 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, the system 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, the system 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, the system 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, the system 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 the system 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, the system 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
