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:
Configure the Account Search Handler.
Register a Veeva Network instance.
Create a system in Veeva Network.
Configure the required field mappings.
Translate custom labels.
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
andemails
toMED_Contact_Information__c.MED_Phone__c
andMED_Contact_Information__c.MED_Email__c
respectively. On the other hand, if you use the mvn.MED_NetworkSearchHdlr class, onlyMED_Address
type Contact Information fields can be searched on and returned. Other types, likeMED_Phone
orMED_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:Navigate to the
MED_MDM_Connection__mdt
custom metadata type.Click Manage MDM Connections.
Click New.
Add the information shown in the table below.
Table 157. MDM Connection Veeva Network Field SetupField 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 isMIC
. 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.
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:
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 158, “Fields on records passed” lists the fields that the passed records have.Table 158. Fields on records passedVeeva 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 StructureThe 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' }
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.