Data model

Key Network/IDN field

A new field, key_hco_network__v, is added to the HCO object to help you identify the top-level HCOs that are considered key networks (or integrated delivery networks (IDNs)) in your Network instance.

This checkbox field is managed by Veeva OpenData.

The field will be enabled by default in new Network instances. You can enable it for your existing Network instance.

Field label

The label that displays on record profiles depends on the HCO’s primary country.

• US – IDN?

• All other countries – Key Network?

Example IDN field on a record profile

Key points

• Changes - The field value cannot be changed by submitting DCRs to OpenData.

  If you would like to manage your own list of IDNs, you can use a custom field.

• Hierarchy Explorer - The field is available to use in the widget so you can navigate the hierarchies of HCOs at the top of the network. The field is added to the hierarchy index by default.

• Reporting on OpenData - The field is added to the flat hierarchy table for OpenData instances and on the flat ownership hierarchy table for OpenData US subscriptions (Reports > SQL Query Editor).

• Search - Use the #KeyNetworks or #IDN hashtags to find these HCOs in your Network instance.

IDN requirements (US only)

In the US, OpenData teams identify IDNs/Key Networks using the following criteria.

Key Network Criteria	Health System	Single Hospital Networks	Regional Health Systems	Practice Networks
Is Top Parent?	Yes	Yes	No	-
Is Owned by Health System	-	-	Yes	No
Minimum Number of Hospitals Owned	2	1	1	5
Minimum Number of HCOs Owned	-	5	5	5
Minimum Number of Affiliated HCPs (to owned HCOs)	100	50	100	100
Key Network Examples	May Clinic, Sutter Health	University Health System	UCLA Health, Dignity Health	Texas Oncology, Florida Cancer

Key Network Requirement (UK)

In the UK, OpenData identifies Key Networks using the following criteria:

• HCO Type = Integrated Care System (ICS)

  (hco_type__v = 36_21)

Example Key Network: North West London ICS

Primary support for sub-objects

The Unique Checkbox primary calculation options that were previously available only for addresses are now supported for licenses, parent HCOs, and custom sub-objects.

Administrators can now use these options to allow Network to recalculate a Unique Checkbox primary on any sub-object for specific conditions. Using these recalculation options or custom logic gives you more flexibility for defining a primary.

This enhancement is available by default in your Network instance. It is supported for Unique Checkbox primary configurations only.

Important: The updates to Unique Checkbox on licenses does not impact the mapping of licenses to Veeva CRM.

Unique Checkbox options

The Unique Checkbox primary configuration ensures that the primary flag does not move from an object so your business processes can depend on the setting. The calculation options allow Network to recalculate the primary for specific conditions to ensure that a record always has a primary; for example, if the existing primary object becomes inactive or invalid.

When you create a primary type field and choose the Unique Checkbox configuration, the calculation options display when a sub-object is selected in the Network Object field for the Country Visibility and Field Rules.

The When to Calculate Primary options display in the Properties section.

You can select any combination of these options to allow Network to calculate the primary for specific situations:

• The record DOES NOT HAVE a primary - For records that do not have a primary defined (the field has no value (-) or the value is set to Unknown or No/False) Network will set a primary. Only valid, under review, and active objects are considered.

• The status of the primary is INACTIVE - For primary sub-objects where the record status is Inactive, Network will recalculate a primary address.

  If there are no active objects on the record, a primary is not calculated so the record will not have a primary.

  • Recalculate only if there are active <objects> on the record - Network only recalculates the primary if there are objects addresses on the record. If there are no active objects, Network keeps the primary on the object that was last active.

    This option ensures that the record has a primary even if the object is inactive.

• The record state of the primary is INVALID or DELETED - For primary objects that have been reviewed and are considered invalid, Network will recalculate a primary.

By default, none of these options are selected, so the primary setting will not move from a sub-object that uses the Unique Checkbox configuration.

Multiple primary fields can be created for a sub-object using the Unique Checkbox configuration, so you can define primary addresses with each specific behavior to support your business needs.

Primary logic

The Primary Address Recalculation Logic section displays if any of the calculate options have been selected.

When Network recalculates a primary, specific fields are matched against the existing sub-object record to find the best primary.

You can define custom logic to specify the fields that you want Network to consider during the primary recalculation. This ensures that the record that is the most relevant for your business purposes is selected as primary. For example, using Network's standard logic, an address that is outside of the sales territory could be calculated as the new primary because the standard recalculation logic does not consider postal codes.

Note: Recalculation logic runs when the existing primary sub-object defined on a record becomes disqualified.

Choose one of the options:

• Use standard logic - Standard logic considers the following fields: source rank, last updated date and time of the primary field, and the newest Veeva ID on the sub-object. This is selected by default.

• Define custom logic - Define the fields that you want Network to use for recalculating a primary. A maximum of three conditions can be defined.

  Example

  To ensure that the primary affiliation is in the same sales territory as the HCP or HCO, add the entity address ID as a custom condition.

  

Exclude sub-objects

Network automatically excludes sub-objects that are Invalid and Inactive. You can define additional sub-object criteria to exclude from the primary recalculation. A maximum of three custom exclude criteria can be added.

Standard logic recalculation

When Network recalculates the primary using standard logic, the following steps are taken:

1. Run Inactive/Invalid logic - Exclude sub-objects that are Inactive or Invalid.

2. Run the exclude logic - Remove any sub-objects for primary consideration based on the exclude criteria you have defined.

3. Run the standard condition logic - Network recalculates the best primary based on the order of the standard conditions: source rank, last updated date and time, and the newest Veeva ID

Custom logic recalculation

When Network recalculates the primary using custom logic, the following steps are taken:

1. Run Inactive/Invalid logic - Remove sub-objects that are Inactive or Invalid.

2. Run the exclude logic - Remove any sub-objects for primary consideration based on the exclude criteria you have defined.

3. Run the custom condition logic - If the first condition is met, then the sub-object with the condition is the new primary. If multiple sub-objects match the conditions, the sub-object with the most matches is the new primary. If the condition is not met, move on to the next condition.

4. Run standard logic - If multiple sub-objects match the current primary with the same number of matches, Network uses the standard logic conditions as a tie-breaker to recalculate the new primary. Only the sub-objects that matched the custom conditions are considered.

Profile layouts

NAStandard layout for HCOs

A section called Hierarchy is added to the default NAStandard profile layout for HCOs. It is located between the General Information and External Identifiers section.

The Hierarchy section contains the following fields on the HCO object:

• immediate_parent__v – Entity ID of the HCO Parent with 'Ownership' Relationship Type.

• hospital_parent__v – Entity ID of the Hospital the HCO rolls up to.

• regional_health_system__v – Entity ID the HCO rolls up to that is a child of a Health System and has key_hco_network__v = 'Y'

• top_parent__v field - Top parent for this entity.

These fields are managed by Veeva OpenData and are read only; they cannot be changed by submitting data change requests.

Example Hierarchy section on US HCO record profiles

This enhancement is enabled by default in your Network instance.

Country support

Veeva OpenData data models have been added for the following countries:

• Algeria (DZ)
• Cameroon (CM)
• Cote d'Ivoire (CI)
• Cyprus (CY)
• Ghana (GH)
• Israel (IL)
• Kenya (KE)
• Malta (MT)
• Mauritius (MU)
• Morocco (MA)
• Senegal (SN)
• South Africa (ZA)
• Tunisia (TN)

These countries will be managed in the EMEA OpenData instance.

The data models are based on the Other Countries (ZZ) data model. The data model also includes additional fields so they are consistent with other data models supported by the EMEA OpenData team.

The activated reference codes are based on the reference codes that are activated for Other Countries (ZZ), along with additional reference codes supported by the EMEA OpenData team.

Localization

The Network UI, data model, and reference codes use the following languages for each country.

Country	Network UI and Data Model	Reference Codes
Algeria (DZ)	French (fr)	French (fr)
Cameroon (CM)	English (en), French (fr)	English (en), French (fr)
Cote d'Ivoire (CI)	French (fr)	French (fr)
Cyprus (CY)	English (en)	Greek (el), Turkish (tr)
Ghana (GH)	English (en)	English (en)
Israel (IL)	English (en)	Hebrew (he)
Kenya (KE)	English (en)	English (en)
Malta (MT)	English (en)	English (en)
Mauritius (MU)	English (en)	English (en)
Morocco (MA)	French (fr)	French (fr)
Senegal (SN)	French (fr)	French (fr)
South Africa (ZA)	English (en)	English (en)
Tunisia (TN)	French (fr)	French (fr)

Data privacy opt out

Veeva OpenData now manages HCP opt outs in the following countries:

• Algeria (DZ)

• Cameroon (CM)

• Cote d'Ivoire (CI)

• Cyprus (CY)

• Ghana (GH)

• Israel (IL)

• Kenya (KE)

• Malta (MT)

• Mauritius (MU)

• Morocco (MA)

• Senegal (SN)

• South Africa (ZA)

• Tunisia (TN)

Two data model fields have been enabled for these countries for the HCP object:

• data_privacy_opt_out__v

• data_privacy_opt_out_date__v

Records that are opted-out by Veeva OpenData do not display and cannot be accessed in downstream systems. This ensures data privacy for opted-out HCPs to satisfy regional regulatory requirements.

Opted-out countries

To review the list of opted-out countries, in the Admin console:

1. Click Data Model > Data Domains and choose the Customer Master domain.

2. Select the Health Care Professional object and find the data_privacy_opt_out__v field in the Fields section.

3. Click the field to review the list of opted-out countries that are managed by Veeva OpenData.

Formatted name

A custom calculation has been added for the formatted_name__v field for Vietnam. The formatted name uses values from several name fields to display a complete name for an HCP.

This enhancement is enabled by default in your Network instance.

Name calculation

HCP names for Vietnam are calculated using these Veeva fields in the following order:

<last_name__v> <first_name__v>

Note: There is a space between the Last Name and First Name fields.

The formatted name displays on the profile page.