Skip to main content

Veeva Network

Medical Information Cloud supports out-of-the-box integration with Veeva Network to facilitate Account search, both as a result of manual account searches and account lookups for inbound MIRFs. Additionally, Medical Information Cloud supports the ability to create and deliver Data Change Requests (DCRs) to Veeva Network resulting from data changes within Medical Information Cloud.

The steps required to connect and leverage a Veeva Network instance within Medical Information Cloud are as follows:

  1. Configure the Account Search Handler.

  2. Register a Veeva Network instance.

  3. Create a system in Veeva Network.

  4. Configure the required field mappings.

  5. Translate custom labels.

  6. Configure data change request (DCR) creation.

Special considerations

Keep these considerations in mind when setting up the Veeva Network integration. Due to API and data model differences between Medical Information Cloud and Veeva Network, these restrictions and limitations exist in the out-of-the-box Veeva Network integration:

  • Network Results are very heavy and can hit a fatal CPU Limit when processing results in some situations. It is recommended to set the Account Search Max Results to 75 or less to avoid this issue.

  • Restrict to Selected Institution and Restrict to Selected Person account search filters are not supported and the filter will not be applied when retrieving Network results.

  • If you use the beta mvn.MED_NetworkSearchHdlrV3 class, you can properly search and map network phones and emails to Contact Information records by mapping the special network fields of phones and emails to MED_Contact_Information__c.MED_Phone__c and MED_Contact_Information__c.MED_Email__c respectively. On the other hand, if you use the mvn.MED_NetworkSearchHdlr class, only MED_Address type Contact Information fields can be searched on and returned. Other types, like MED_Phone or MED_Email cannot be mapped or searched. The Veeva Network data model does not have phone or email-related lists. Instead, it has many phone and email fields on both the Account and Address. This causes severe challenges when trying to search for phone and email addresses in the network and locally at the same time. Very careful planning and possibly custom data replication may be necessary to achieve an acceptable user experience for these types of searches with mvn.MED__NetworkSearchHdlr.

Step 1 - Configure Account Search Handler

For information on how to enable Medical Information Cloud to search for accounts within registered Veeva Network instances, visit the configuration section of Account Search.

To enable the Account Search handler, edit the existing global setting custom metadata type entry and update the Account Search Handler Classes value to include the desired search handlers. Visit Master Data Management for instructions.

Configure searching and mapping of phones and emails

If you use the mvn.MED_NetworkSearchHdlrV3 class with the mvn.MED_IAccountSearchV3 interface, you can search and map the special network fields of phones and emails onto the MED_Phone__c and MED_Email__c fields on Contact Information (MED_Contact_Information__c) records. To configure this, create an MDM Field Mapping (MED_MDM_Field_Mapping__mdt) metadata record for the phones and emails special values you wish to search or map.

Warning

This is a beta feature. To fix any issues, clone the search handler and follow the customization guidelines.

Step 2 - Register Veeva Network instances

Each Veeva Network instance that is to be integrated with Medical Information Cloud must be registered within the Medical Information Cloud configuration. Visit the Master Data Management topic for instructions.

Note

Default values are shown below. We recommend changing these according to your organization's needs.

  • Create MDM Connection (MED_MDM_Connection__mdt) records:

    1. Navigate to the MED_MDM_Connection__mdt custom metadata type.

    2. Click Manage MDM Connections.

    3. Click New.

    4. Add the information shown in the table below.

    Table 136. MDM Connection Veeva Network Field Setup

    Field label

    Default value

    Required (Yes/No)

    Label

    Veeva Network

    Yes

    MDM Connection Name

    Veeva_Network.

    Yes

    Segment

    Search for and select Default_Segment

    Yes

    Default Mapping

    Leave unchecked.

    Note

    If the MED_Default_Mapping__c checkbox is checked, this connection will not be considered a real connection, but rather a template/default mapping for all other connections using the same handler class. These field mappings are added to the field mappings on the other connections. If there is a conflict, the real/non-default checked field mapping overrides it.

    Handler Class

    MED_NetworkSearchHdlr

    Yes

    MDM Named Credentials

    Veeva_Network

    MDM Session Timeout

    Although this is optional, we recommend it be set to slightly less than the session timeout configured for Veeva Network. If left blank, a value of 900 is used.

    MDM Call Timeout

    60,000

    Network OpenData Search

    Select "Defer to Network Instance Config" from the dropdown.

    Supplemental HCOs

    Select None from the dropdown.

    Custom Key Generator Class

    MED_NetworkCustomKeyGenerator



  • Configure named credentials.

These two components work in conjunction to enable access to Veeva Network from Medical Information Cloud and must be configured correctly to ensure communication between the two applications.

Veeva Network search scope

Administrators can configure the scope of data to be searched within the Veeva Network by Medical Information Cloud. By default, searches sent to Veeva Network by Medical Information Cloud will defer to the configuration within the associated Veeva Network instance as to whether data collections such as Veeva OpenData are included within the search scope. If you want to control the search scope within Medical Information Cloud, the available configurations are as follows:

  • Include OpenData Results

  • Exclude OpenData Results

  • Defer to Instance Configuration

This configuration is made within the corresponding entry in the MED_MDM_Connection__mdt custom metadata type record on the MED_Network_OpenData_Search__c field.

Named Credentials

In cases where remote Veeva Network instances are being leveraged, named credentials are required to facilitate the integration. For details on individual field values, please contact Komodo Health Customer Support.

Step 3 - Create a system in Veeva Network

This step is only required if you plan to use custom keys and/or DCRs and does not need to be completed for customers only wanting to search Veeva Network.

  • Create a SYSTEM in Veeva Network using one of the following naming guidelines:

    • The default SYSTEM value is MIC. You can configure the value to something else by editing the Network System Name and Network System Description fields in the MDM Connection record.

    • If you are only using a custom key generator and not DCRs, you may name the SYSTEM something else.

Visit Veeva Network's documentation for more information.

Step 4 - Required Field Mapping

Field mappings should be configured as instructed in Master Data Management.

Note

One of the fields must be mapped using the RecordTypeId field as shown below.

MIC_MDM_Connection_Field_Map.png

Step 5 - Translate custom labels

This component makes use of the following labels that can be configured within the Salesforce translation workbench to change display text values.

Label Name

Description

MED_Access_Privileges_Network_Error

Used to return an error message when the user has not been granted access to the Network.

MED_Invalid_Session_Network_Error

Used to return an error message when the system is unable to log into the Network due to an Invalid Session.

MED_Other_Network_Error

Used to return an error message when the system got an error which is not covered.

MED_Network_Inactive_User_Error

Error displayed when the Network user is inactive.

MED_User_Locked_Out_Network_Error

Error displayed with the user has been locked out of the Network.

Step 6 - Configure data change request (DCR) creation

You can integrate DCRs generated within Medical Information Cloud with Veeva Network. To facilitate this, two apex batch jobs need to be scheduled to execute on an as-needed basis to facilitate the migration of DCRs and DCR transmission status between the environments.

Scheduling batch jobs

Each batch job is contained within its apex class and needs to be scheduled for execution. The classes are as follows:

  • MED_NetworkSendDCRBatchSched (Hourly is recommended)

  • MED_NetworkRetrieveDCRBatchSched (Daily is recommended)

For help scheduling, visit Salesforce's Schedule Apex Jobs documentation.

On-demand batch job execution

The DCR batch jobs may be executed in an on-demand fashion, which can be helpful when testing system configuration.

To do this, use the Developer Console to execute the following anonymous Apex:

database.executebatch(new MED_NetworkSendDCRBatchSched(), 90); database.executebatch(new MED_NetworkRetrieveDCRBatchSched(), 90);

Veeva Network custom key generation

Each time an Account or Contact Information is copied from a Veeva Network instance, Medical Information Cloud generates and associates a custom key to the corresponding record in Veeva Network to identify which records propagated to Medical Information Cloud.

The default custom keys have this form: MIC-<SFDC Org Id>:<Object Type>:<Object Id>. For example: MIC-00D2C0000000uhfUAA:Account:001000000000001

Create a custom key structure

To define and use a custom key structure:

  1. Create a custom Apex class that defines a custom key structure.

    The custom key class should extend the Callable interface and return a Map<Id,Map<String,Object>> with the ID key being the Salesforce record Id that the custom key is for. For information about the Callable interface, visit Salesforce's developer documentation.

    The class must pass two parameters through the call() interface method:

    • An action name to indicate the type of entity for which to generate custom keys. Values include:

      • GENERATE_KEYS_FOR_ACCOUNTS

      • GENERATE_KEYS_FOR_PARENT_ACCOUNTS

      • GENERATE_KEYS_FOR_CONTACT_INFO

    • An argument map containing the mdmConnectionId for a MED_MDM_Connection__mdt record and the records for the list of objects that you want to get the custom keys for. Table 137, “Fields on records passed lists the fields that the passed records have.

      Table 137. Fields on records passed

      Veeva Network object

      Medical Information Cloud object

      Medical Information Cloud fields

      Account

      Account

      • ID

      • IsPersonAccount

      • MED_External_Id__c

      • RecordType.DeveloperName

      • RecordTypeId

      Parent Account (HCOs)

      Account

      • ID

      • IsPersonAccount

      • MED_External_Id__c

      • RecordType.DeveloperName

      • RecordTypeId

      Address

      Contact Information

      • MED_External_ID__C

      • ID

      • RecordType.DeveloperName



    The required key structure for GENERATE_KEYS_FOR_ACCOUNTS and GENERATE_KEYS_FOR_CONTACT_INFO is:

    {    
        ‘custom_key_source_type__v' =>string,
        'custom_key_value__v'=>string,
        'system_name'=>string,
        ‘vid_key’=>string,
        ‘custom_key_item_type__v’=>string
    }

    For GENERATE_KEYS_FOR_PARENT_ACCOUNTS, vid_key is the only required value. All other map values are ignored.

    {   
        ‘vid_key’=>string
    }
    Example 16. Account Key Structure

    The default key implementation returns the following for an account:

    {
        ‘custom_key_source_type__v' : 'MIC-'<OrganizationID>,
        'custom_key_value__v': <Account Id>,
        'system_name': 'MIC',
        ‘vid_key’:'Network:Entity: <Account Id>,
        ‘custom_key_item_type__v’:'Account'
    }


  2. Change the Custom Key Generator Class value on the corresponding MDM Connection custom metadata type record to the name of the custom Apex class created in the previous step.

Once configured, Medical Information Cloud uses the custom key to build identifying information for Accounts and Contact Information on Update and Insert between Veeva Network and Medical Information Cloud. Medical Information Cloud maintains responsibility for transmitting the custom key.