Data security practices

As Agents are responding to inbound requests within Medical Information Cloud Inquiry Management, one of the key steps is to conduct an account search to associate a Requester, Institution, or Referred By to a given Interaction. The account search interface allows agents to search for existing accounts or create a new account if it does not already exist.

By default, account searches are limited to records that already exist within your Salesforce system. This search scope can be increased to include a search within your Master Data Management solution. Medical Information Cloud Inquiry Management supports integration with Veeva Network, allowing agents to search not just their organization’s instance of Veeva Network but also the Veeva OpenData repository that contains approximately 16 million healthcare professionals (HCPs), healthcare organizations (HCOs), and their affiliations worldwide.

Once enabled, when an Agent initiates a search within Medical Information Cloud Inquiry Management a request is sent from your Salesforce system to your Veeva Network Instance’s API to collect any results that match the entered search criteria. All requests to Veeva Network are performed over HTTPS, leveraging a single integration user account that is authenticated for each request.

Details on the Veeva Network API can be found on the Veeva Network Developer Site.

As agents are responding to inbound requests, they can access and search your organization’s content repository for approved content or resource documents that help ensure they are responding appropriately. Medical Information Cloud Inquiry Management offers native connectors for both Medical Information Cloud Content Management and Veeva Vault as well as a framework to support additional Content Management Systems through an extension of the core product.

In the case of Veeva Vault, once it is enabled document searches performed by Agents are sent from your Salesforce system to your Veeva Vault system to retrieve search results that align that match the entered search criteria and align to the visibility afforded the Agent within Vault. Selected search results are then associated with the given request, and referenced later in the Fulfillment Package Generation integration described above.

All requests are initiated from within your Salesforce system by an Agent, performed over HTTPS, and leverage the Veeva Vault API to submit search requests and receive back results.

For details on Veeva Vault's delegated authentication, visit About Delegated Authentication.

In cases where Accounts within Medical Information Cloud Inquiry Management are maintained by data stewards and/or a data governance program, Medical Information Cloud Inquiry Management supports the ability to generate data change requests. A data change request (DCR) is a requested change to a record that is maintained by a 3rd party. By default, DCRs are generated and housed within your Salesforce system. You can also enable an integration with your Master Data Management systems to propagate generated DCRs as well as receive back the results once they have been reviewed by the appropriate party.

Once enabled, a scheduled routine will periodically send any DCR updates from your Salesforce system to your Master Data Management system. Additionally, there is a scheduled routine to retrieve DCR results in your Master Data Management system from your Salesforce system.

Presently Medical Information Cloud Inquiry Management supports Veeva Network as a Master Data Management solution. However, additional systems can be supported through customization. When integrating with Veeva Network, communication with your Veeva Network Instance’s API is performed over HTTPS, leveraging a single integration user account that is authenticated for each request.

Details on the Veeva Network API can be found on the Veeva Network Developer Portal.

A Fulfillment is a package of information that is sent to the requester via email, mail, or fax. Typically, this package is constructed of one or more pieces of content, that are often time managed independently of one another. Once enabled and initiated by an authorized user, Medical Information Cloud Inquiry Management leverages a 3rd party service from Nintex to assemble the selected, distinct pieces of content and assemble them into a single, compliant PDF that can be sent in response to the inbound request.

To facilitate this, a request is sent from your Salesforce system at the request of a user to initiate the compilation of the selected pieces of content. As part of this request, links to the selected documents and records in your source systems are included. Nintex’s system then iterates over the provided links, authenticates into each source system, and retrieves the content. Once retrieved, the individual documents and records are merged into a single PDF and stored within your Salesforce system.

Throughout this process, all processing is performed in memory, and at no point are your source or target documents stored within Nintex’s systems. All requests from Nintex to your content repository are authenticated before subsequent processing.

Medical Information Cloud Inquiry Management offers out-of-the-box support for Salesforce and Veeva Vault as content repositories. However, you may implement your own connections to any internet-accessible system.

Increasingly, medical inquiries are coming from indirect sources, such as commercial organizations. To support the receipt of medical inquiries from 3rd Party systems, Medical Information Cloud Inquiry Management has a Medical Inquiry Request Form integration framework that allows you to integrate other systems that are capturing requests that need to be routed to a medical information agent.

Medical Information Cloud Inquiry Management currently offers a native connector for Veeva CRM to both receive inbound MIRFs and update statuses ongoing of received records. Both Medical Information Cloud Inquiry Management and Veeva CRM are based on top of the Salesforce platforms and leverage the Salesforce APIs to communicate information back and forth. Scheduled jobs are responsible for the periodic transfer of information between systems, all of which initiate within your Salesforce systems. Requests in both directions are done so with a single integration user account (in each Salesforce org) that can be configured with its own security and privileges to ensure secure communications. Lastly, all communication is performed via HTTPS over TLS 1.1 or greater and adheres to the security configuration within your Salesforce system.

Details on the Salesforce APIs can be found on the Salesforce Developer Portal.

Medical Information Agents can generate snapshots of inbound requests to send to any team or user outside of Medical Information Cloud Inquiry Management if requested. Snapshots are PDF files containing information from designated Interaction, Request, Adverse Event, or Product Quality Complaint records and can either be generated with our Nintex integration or our in-house solution. Refer to Nintex integration vs. in-house solution. The PDF files can then be shared externally as needed.

For our Nintex integration, Medical Information Cloud Inquiry Management leverages a 3rd party service from Nintex to assemble the individual portions of data into a single PDF document. Once initiated, a request is sent from your Salesforce system to Nintex to initiate the process of assembling the content into a PDF. As part of the request, the unique identifier of the relevant record within your Salesforce system is sent in addition to the configured set of instructions advising Nintex what additional data components to retrieve. Nintex then processes the received instructions, generates a PDF per the administrative setup within your Salesforce system, and then stores the resulting document back into your Salesforce system.

Throughout this process, all processing is performed in memory, and at no point are your source or target documents stored within Nintex’s systems. All requests from Nintex to your content repository are authenticated before subsequent processing.

For our in-house solution, the PDF document is generated and stored natively within your Salesforce system throughout the entire process.