Sub-object match rules

Duplicate sub-objects are matched and merged using key matching (custom keys are the same) and field matching (using sub-object comparison rules). Key matching is not available for Parent HCO objects; they are matched using field matching only.

Sub-object comparison rules

Network contains a set of default sub-object comparison rules that are applied in any merge comparison. These rules are not visible in the Network UI.

Addresses

Addresses are compared to each other only if they have the same address verification 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.

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.

Fields used in comparison rules

The following fields are used for each sub-object to compare for duplicates.

Address License Parent HCO

The following fields 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__v instead)

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__v instead)
  • hierarchy_type__v

Example - Merge a local address into a Veeva OpenData address

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

HCP - Veeva OpenData record

VID First Name Last Name NPI Number
VID1 Bob Smith 9925125

Address - 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 is added to the record.

Address - 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.

As the update is taking place in your Network instance, the address verification statuses are compared and found to be identical, so the default sub-object comparison rules 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 - 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