# Inbox Item Study and Product Matching

Vault matches study and product data in cases imported from structured source files (E2B, JSON, or CSV) to the relevant _Studies_ and _Products_ in your Vault associated with the _Organization_ specified in the source file. When Vault finds a match, it populates the _Company Product_ field on the generated _Inbox Item_ and, when applicable, <a href="/en/lr/01162/">auto-codes</a> the product. When configured by your Admin, Vault considers [confidence criteria][1] to determine the threshold at which Vault performs _Product_ matching and populates the _Product Match Confidence_ and _Product Match Criteria_ fields. 

The following flowchart shows how Vault matches during import:

<a href="https://platform.veevavault.help/assets/images/saf-study-product-matching-flowchart.png" data-lightbox="saf-study-product-matching-flowchart.png" data-title="" data-alt="Study and Product Matching Flowchart">
  <img class="docimage" src="https://platform.veevavault.help/assets/images/saf-study-product-matching-flowchart.png" alt="Study and Product Matching Flowchart" style="max-width: 60%;"  />
</a>

## Study Matching {#study-matching}

Vault matches _Studies_ and _Study Registrations_ using the following scenarios in priority order:

* **Scenario 1**: For E2B(R3) and JSON, if the E2B or JSON file contains at least one valid _Study Registration_, Vault matches the _Study_ using the _Registration Number_ and _Country_ on _Study Registrations_.
  * **E2B(R3)**: _Study Registration_ must contain valid C.5.1.r.1 Study Registration Number and C.5.1.r.2 Study Registration Country values.
  * **JSON**: _Study Registration_ must contain _Registration_ (`registration_number__v`) and _Country_ (`country__v`) fields.
* **Scenario 2**: For E2B(R3), E2B(R2), and JSON, Vault matches the _Study_ using the _Study Number_.
* **Scenario 3**: For E2B(R3) and E2B(R2), Vault matches the _Study_ using the <a href="/en/lr/01216/#study-number-aliases">_Study Number Alias_</a>.

The _Study_ record must contain all registrations contained in an E2B(R3) file for Vault to consider it a match. Vault does not match if any E2B C.5.1.r.1 Study Registration Number or C.5.1.r.2 Study Registration Country conflict with the _Registration Numbers_ and _Countries_ values of the _Study_ in your Vault. 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 the C.5.3 Study Number value does not match any _Study_ in your library, Vault does not match any _Studies_ and the E2B notification logs a warning. 

The following table describes Vault's matching logic:

<table>
   <thead>
      <tr>
         <th rowspan="2">Scenario</th>
         <th colspan="5">Matching</th>
         <th rowspan="2">Result</th>
      </tr>
      <tr>
         <th>E2B(R3)</th>
         <th>E2B(R2)</th>
         <th>JSON</th>
         <th>Vault Object</th>
         <th>Vault Field</th>
      </tr>
   </thead>
   <tbody>
      <tr>
         <td rowspan="2">1</td>
         <td>C.5.1.r.1</td>
         <td>N/A</td>
         <td><code>registration_number__v</code></td>
         <td><em>Study</em> > <em>Study Registration</em></td>
         <td><em>Registration Number</em> (<code>registration_number__v</code>)</td>
         <td rowspan="2">
            <ul>
               <li>Study link added to the <em>Case</em> > <em>Study</em> (<code>study__v</code>) field.</li>
               <li>Study registration link added to the <em>Case</em> > <em>Study Registration</em> (<code>study_registration__v</code>) field.</li>
            </ul>
         </td>
      </tr>
      <tr>
         <td>C.5.1.r.2</td>
         <td>N/A</td>
         <td><code>country__v</code></td>
         <td><em>Study</em> > <em>Study Registration</em></td>
         <td><em>Country</em> (<code>country__v)</code></td>
      </tr>
      <tr>
         <td>2</td>
         <td>C.5.3</td>
         <td>A.2.3.2</td>
         <td><code>name__v</code></td>
         <td><em>Study</em></td>
         <td><em>Name</em> (<code>name__v</code>)</td>
         <td>
            <ul>
               <li>Study link added to the <em>Case</em> > <em>Study</em> (<code>study__v</code>) field.</li>
               <li><em>Study Registration</em> not matched.</li>
            </ul>
         </td>
      </tr>
      <tr>
         <td>3</td>
         <td>C.5.3</td>
         <td>A.2.3.2</td>
         <td><code>N/A</code></td>
         <td><em>Study Number Alias</em></td>
         <td><em>Name</em> (<code>name__v</code>)</td>
         <td>
            <ul>
               <li>Study link added to the <em>Case</em> > <em>Study</em> (<code>study__v</code>) field.</li>
               <li><em>Study Registration</em> not matched.</li>
            </ul>
         </td>
      </tr>
   </tbody>
</table>

## Study Product Matching

Vault matches _Study Products_ when the following conditions are met:

* The study matches a _Study_ in your Vault.
* The related _Product_ has a <a href="/en/lr/01215/#prod-use-type">_Product Use Type_</a> of _Company Use_ or is blank.
* The _Product_ is not blinded (G.k.2.5 Investigational Product Blinded or `blinded_protection__v`).
* The _Drug Role_ (G.k.1/B.4.k.1 Characterisation of Drug Role or `drug_role__v`) must be _Suspect_, _Interacting_, _Drug Not Administered_, or unspecified (null). If unspecified, Vault sets the _Drug Role_ to _Suspect_ on import.

Vault assigns the _Rank_ of _1_ (primary) to the first matched _Case Product_ with a _Drug Role_ of _Suspect_. If there are no _Case Products_ with a _Drug Role_ of _Suspect_, Vault assigns  the _Rank_ of _1_ (primary) to the first imported _Study Product_. If Vault can't find a match, Vault generates a _Case Product_ as an _External Product_ type.

The following table describes Vault's matching logic:

<table>
   <thead>
      <tr>
         <th rowspan="2">Scenario</th>
         <th colspan="5">Matching</th>
         <th rowspan="2">Result</th>
      </tr>
      <tr>
         <th>E2B(R3)</th>
         <th>E2B(R2)</th>
         <th>JSON</th>
         <th>Vault Object</th>
         <th>Vault Field</th>
      </tr>
   </thead>
   <tbody>
      <tr>
         <td>1</td>
         <td>G.k.2.1.1b</td>
         <td>N/A</td>
         <td><code>mpid__v</code></td>
         <td><em>Study Product</em> > <em>Product Registration</em></td>
         <td><em>MPID</em> (<code>mpid__v</code>)</td>
         <td rowspan="5">
            <ul>
               <li>Product link added to the <em>Case Product</em> > <em>Study Product</em> (<code>study_product__v</code>) field.</li>
               <li><em>Case Product</em> > <em>Product Type</em> (<code>object_type__v</code>) is set to <em>Study Product</em>.</li>
            </ul>
         </td>
      </tr>
      <tr>
         <td>2</td>
         <td>G.k.2.1.2b</td>
         <td>N/A</td>
         <td><code>phpid__v</code></td>
         <td><em>Study Product</em> > <em>Product Registration</em></td>
         <td><em>PhPID</em> (<code>phpid__v</code>)</td>
      </tr>
      <tr>
         <td>3</td>
         <td>G.k.2.3.r.2b</td>
         <td>N/A</td>
         <td><code>term_id__v</code></td>
         <td><em>Study Product</em> > (all) <em>Study Product Substances</em></td>
         <td><em>Substance TermID</em> (<code>term_id__v</code>)</td>
      </tr>
      <tr>
         <td>4</td>
         <td>G.k.3.1</td>
         <td>B.4.k.4.1</td>
         <td><code>registration_number__v</code></td>
         <td><em>Study Product</em> > <em>Product Registration</em></td>
         <td><em>Registration Number</em> (<code>registration_number__v</code>)</td>
      </tr>
      <tr>
         <td>5</td>
         <td>G.k.2.2</td>
         <td>N/A</td>
         <td><code>name__v</code></td>
         <td><em>Study Product</em></td>
         <td><em>Name</em> (<code>name__v</code>)</td>
      </tr>
   </tbody>
</table>

If none of the above scenarios identify a match, Vault attempts to match the _Study Product_ using the _Blinded Name_ (for example, "Placebo" instead of "Cholecap"). If no match is found, Vault attempts [non-<em>Study</em> matching][3].

## Product Matching (Non-Study) {#non-study}

Vault matches the imported product to unblinded _Products_ in your Vault. To match, the _Product_ must have a <a href="/en/lr/01215/#prod-use-type">_Product Use Type_</a> of _Company Use_ or blank. Vault assigns the _Rank_ of _1_ (primary) to the first matched _Case Product_ with a _Drug Role_ of _Suspect_. If there are no _Case Products_ with a _Drug Role_ of _Suspect_, Vault assigns  the _Rank_ of _1_ (primary) to the first imported _Case Product_. If Vault can't find a match, Vault generates a _Case Product_ as an _External Product_ type.

The following table describes Vault's matching logic:

<table>
   <thead>
      <tr>
         <th rowspan="2">Scenario</th>
         <th colspan="5">Matching</th>
         <th rowspan="2">Result</th>
      </tr>
      <tr>
         <th>E2B(R3)</th>
         <th>E2B(R2)</th>
         <th>JSON</th>
         <th>Vault Object</th>
         <th>Vault Field</th>
      </tr>
   </thead>
   <tbody>
      <tr>
         <td>1</td>
         <td>G.k.2.1.1b</td>
         <td>N/A</td>
         <td><code>mpid__v</code></td>
         <td><em>Product</em> > <em>Product Registration</em></td>
         <td><em>MPID</em> (<code>mpid__v</code>)</td>
         <td rowspan="3">
            <ul>
               <li>Product link added to the <em>Case Product</em> > <em>Product</em> (<code>product__v</code>) field.</li>
               <li>Product registration link added to the <em>Case Product</em> > <em>Product Registration</em> (<code>product_registration__v</code>) field.</li>
               <li><em>Case Product</em> > <em>Product Type</em> (<code>object_type__v</code>) is set to the type on the matching <em>Product</em>.</li>
            </ul>
         </td>
      </tr>
      <tr>
         <td>2</td>
         <td>G.k.2.1.2b</td>
         <td>N/A</td>
         <td><code>phpid__v</code></td>
         <td><em>Product</em> > <em>Product Registration</em></td>
         <td><em>PhPID</em> (<code>phpid__v</code>)</td>
      </tr>
      <tr>
         <td>3</td>
         <td>G.k.3.1</td>
         <td>B.4.k.4.1</td>
         <td><code>registration_number_v</code></td>
         <td><em>Product</em> > <em>Product Registration</em></td>
         <td><em>Registration Number</em> (<code>registration_number_v</code>)</td>
      </tr>
      <tr>
         <td>4</td>
         <td>G.k.2.2</td>
         <td>B.4.k.2.1</td>
         <td><code>name__v</code></td>
         <td><em>Product</em></td>
         <td><em>Name</em> (<code>name__v</code>)</td>
         <td>
            <ul>
               <li>Product link added to the <em>Case Product</em> > <em>Product</em> (<code>product__v</code>) field.</li>
               <li><em>Case Product</em> > <em>Product Type</em> (<code>object_type__v</code>) is set to the type on the matching <em>Product</em>.</li>
            </ul>
         </td>
      </tr>
   </tbody>
</table>

If none of the above scenarios identify a match, Vault attempts [product and substance alias matching][4].

## Product and Substance Alias Matching {#product-substance-alias-match}

Vault matches the reported _Case Product_ to a <a href="/en/lr/01215/#alias">_Product Alias_</a> and links the reported _Case Product_ to the existing _Product_. If this does not identify a match, Vault matches the reported _Product Substance_ to a _Substance Alias_ and links the reported _Product Substance_ to the _Product_ associated with the _Substance Alias_. If Vault can't find a match, Vault generates a _Case Product_ as an _External Product_ type.

There must be an absolute match for Vault to match the reported _Case Product_ to an existing _Product_:

1. **Absolute Match**: If there are multiple reported substances that match one _Product_ in your library, Vault links the reported _Case Product_ to the respective _Product_. In the following example, the reported _Case Product_ matches "Cholecap".
2. **No Match**: If the reported substances match to different _Products_ in your library, Vault does not match a _Product_. Similarly, if a reported substance matches multiple _Products_ in your library, Vault does not match the associated _Product_ for the reported substance. In the following example, the reported _Case Product_ does not match to either "DrugX" or "Cholecap".

The following diagram shows an example of an absolute match and no match:

<a href="https://platform.veevavault.help/assets/images/saf-absolute-non-absolute-alias-match.png" data-lightbox="saf-absolute-non-absolute-alias-match.png" data-title="" data-alt="Absolute and Non-Absolute Alias Match">
  <img class="docimage" src="https://platform.veevavault.help/assets/images/saf-absolute-non-absolute-alias-match.png" alt="Absolute and Non-Absolute Alias Match" style="max-width: 75%;"  />
</a>

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

Vault matches blinded _Study Products_. 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 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. Vault assigns the _Rank_ of _1_ (primary) to the _Blinded Name_ of the first matching _Study Product_. 

The following diagram shows how Vault performs _Blinded Name_ (_Study Product Placeholder_) matching for an E2B or JSON with blinded _Studies_:

<a href="https://platform.veevavault.help/assets/images/saf-blinded-name-matching-flowchart.png" data-lightbox="saf-blinded-name-matching-flowchart.png" data-title="" data-alt="Blinded Name Matching Flow">
  <img class="docimage" src="https://platform.veevavault.help/assets/images/saf-blinded-name-matching-flowchart.png" alt="Blinded Name Matching Flow" style="max-width: 50%;"  />
</a>

## Company Product Match Verification {#company-product-match-verification}

When <a href="/en/lr/01191/">configured by your Admin</a>, Vault considers advanced criteria when matching products on generated _Inbox Items_. Vault populates the following fields for each evaluated company product to indicate the confidence assessment and match criteria:

* **Product Match Confidence**: Indicates the confidence score of the match:
  * _1 - Exact Match (ID Match)_
  * _2 - Confident Match_
  * _3 - Likely Match_
  * _4 - Unlikely Match_
  * _5 - Unknown_
  * _6 - No ID or Name Match_
* **Product Match Criteria**: Indicates which fields Vault evaluated to identify a match:
  * _Country_
  * _Dose Form_
  * _Route of Administration_

If Vault does not identify a match within the intake settings defined by your Admin, the _Company Product_ field remains blank. You can override the assigned value if the confidence criteria are not met.

During matching, Vault prioritizes active _Product Registrations_ and populates a _Product Match Confidence_ based on your Admin's <a href="/en/lr/01191/#must-match-and-should-match-confidence-outcomes">configured confidence criteria</a>. However, when the best match is a <a href="/en/lr/01215/#inactive">deprecated _Product Registration_</a>, Vault populates _4-Unlikely Match_ as the _Product Match Confidence_, regardless of other criteria.

<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>: Advanced company product match verification does not apply to <em>Study Products</em>.</p>
    </div>
  </div>
</div>



### Unknown Formulation Product Matching

Vault can code reported products that are missing dose form information to company products with <a href="/en/lr/01215/#unknown-formulation-products">unknown formulations</a>. When verifying a coded _Product_ with an unknown formulation, Vault performs matching against all _Product Registrations_ for the _Product Family_, instead of only those for the coded _Product_.

When importing cases from structured source files that include any ID (MPID, PhPID, or Registration Number), Vault does not attempt to match to unknown formulation products.

[1]: #company-product-match-verification
[2]: #conmeds-exclude
[3]: #non-study
[4]: #product-substance-alias-match
[5]: #product-alias
[6]: #substance-alias