Sub-object match rules

Duplicate sub-objects are matched and merged using the following types of match:

  • Key matching - Custom keys are compared to identify matches.

    Not available for Parent HCO objects; they are matched using field matching only.

  • Field matching - Uses Network's internal sub-object comparison rules to match on specific fields.

Sub-object comparison rules

Network contains a set of internal sub-object comparison rules that are applied in any merge comparison.

Fields used in comparison rules

The following fields are used by default for the Veeva standard sub-objects to compare for duplicates.

Address License Parent HCO

Addresses are compared to each other only if they have the same address verification status.

Fields that are compared for these address verification statuses:

V - Verified, A - Ambiguous, or P - Partially Verified

  • thoroughfare__v
  • premise_number__v
  • locality__v
  • country__v
  • postal_code_primary__v
    (except in China, use
    administrative_area__vinstead)

Fields that are compared for any other verification status:

  • address_line_1__v
  • locality__v
  • country__v
  • postal_code__v
  • license_number__v
  • type_value__v
  • license_degree__v

 
  • parent_hco_vid__v
  • relationship_type__v
    (except in Japan, use
    department_name__vinstead)
  • hierarchy_type__v

Address comparisons

Addresses are compared to each other only if they have the same address verification status.

Address Verification Status Behavior
Same status If the verification status is identical, the default comparison rules are then used.
If the addresses are byte-to-byte identical based on the fields, the addresses are considered a match and are merged.
Different status Addresses could be identical, but if their address verification status differs, the incoming address will not merge into the existing one; it will be added as a new address.

This behavior applies to addresses that are added in any job in Network.

Overridden addresses

  • Existing addresses - Addresses that have been overridden by a Data Steward will never be merged with an incoming address because the address verification statuses will not be the same.

  • New addresses - When new addresses are included in add or change request and they are overridden by the Data Steward that is processing the request, they are not re-cleansed.

Example - Merging addresses

In this example, a locally managed address, Address A, is added to a Veeva OpenData HCP record in your Network instance.

HCP - Veeva OpenData record

VID First Name Last Name NPI Number
VID1 Bob Smith 9925125

Address A - Locally managed

Address verification status = Verified

VID Entity_ID Address_ID Address Line 1 City ZIP Country Custom Key
VID1A   4292154 123 Main Street Salem 97310 United States SAP:Address:4292154

In the Veeva OpenData instance, a new address, Address B, is added to the record.

Address B - Veeva-managed

Address verification status (from the OpenData instance) = Verified

VID Entity_ID Address_ID Address Line 1 City ZIP Country
VID1B   3211750 123 Main Street Salem 97310 United States

The next time the OpenData record is updated in your Network instance, the new Veeva-managed address will be included.

Match comparison

As the update is taking place in your Network instance, the address verification statuses are compared and found to be identical.

This means that the default sub-object comparison rules can compare your locally managed address to the Veeva address.

Result

If the locally managed address matches on the Veeva managed address based on the comparison rules, it is merged into the Veeva address, so one address will be visible on the record - the Veeva address.

HCP - Veeva OpenData record

VID First Name Last Name NPI Number
VID1 Bob Smith 9925125

Address B- Veeva managed

VID Entity_ID Address_ID Address Line 1 City ZIP Country Custom Key
VID1B   3211750 123 Main Street Salem 97310 United States SAP:Address:4292154