Multiple master data ownership

Subscribing to master data from a single source provides the advantage of clearly defined data ownership. With multiple masters within a country, however, there is a risk of conflicting ownership. For example, relationships between HCOs and HCPs might not come from the same master data; they may span multiple masters.

Review the following situations for data ownership considerations.

Parent relationships

HCOs and HCPs might be loaded from a source system that does not also contain their parent HCOs. For example, in an instance where pharmacies and pharmacists are loaded from one source, and all other record types (including hospitals) come from another source (such as Veeva OpenData), a pharmacist working in a hospital would be loaded without workplace information.

Relationships between records from different sources

Data ownership is not visible in downstream systems, for example, by sales reps using Veeva CRM. As a result, a sales rep could submit a change request that includes a relationship between records that are each owned by a different master source.

Change requests that include this kind of relationship are routed to local data stewards. Because each end of the relationship is owned by a different master, neither master can take ownership for the change. Otherwise, if both ends of the relationship are owned by a single master, the change request would be routed to that master source.

HCO or HCP type change

When processing an add request, a master data steward could change an HCO or HCP type to one that is outside the scope of their master data. For example, in an instance where one master source provides pharmacy types and a second master source provides all other types, an add request for a pharmacy would be routed to the first master source.

However, if the first master data steward determines the type should be "Hospital Department" and changes it accordingly, the first master source would be providing you with data (a non-pharmacy HCO type) that should only be provided by the second master source.

Adequate service-level agreements should be in place with all master data providers to ensure that the data stewards processing change requests are aware of the types that are within the scope of their master data. In the previous example, the data steward should reject the add request, as it is outside the scope of the master source.

By sales reps

Sales reps may also change the HCO or HCP type through a change request. In this case, changing the HCO or HCP type for an existing record does not change the record ownership.

Using the previous example, if a sales rep submitted a change from "Pharmacy" to "Hospital Department," the request would still be routed to the first master source, since its original type is within the scope of the first provider. Even after approval, the record would still be owned and controlled by the first provider.

During a merge

A merge of two master records could lead to a change of the HCO or HCP type. Although the type for the surviving record might not be in the scope of the master source, the record would still be downloaded from that master source to the Network instance with the out-of-scope type.

Through data model updates

HCO and HCP types defined by master providers are subject to change. Type definitions are occasionally updated or added and, in turn, sales reps might submit change requests from CRM using the new types.

Before types are added and mapped to CRM (and made available to sales reps), you should first determine how change requests using those types should be routed. Accordingly, you should ensure that third-party master configurations allow for processing of the new types where applicable. This will ensure that change requests are routed properly.

Network Account Search and Search against master

When Search Against Master is enabled and records are downloaded from Veeva OpenData, the system filters parent HCOs to exclude types that are outside of the scope of Veeva OpenData. However, in Veeva CRM, types that are outside of the scope of Veeva OpenData might still be displayed along with the Network Account Search result.

If a sales rep in CRM attempts to download a parent HCO that is outside of the scope of Veeva OpenData, an error appears indicating that the "Entity does not exist."