Skip to main content

Primary objects

The primary objects in Inquiry Management are Interaction, Request, Fulfillment, Adverse Event, and Product Quality Complaint. With these objects, you can record and manage medical inquiries. Specifically, when a Requester reaches out to your Contact Center, you can create a new Interaction record to store the Requester's contact information and information about how and when the Requester contacted the Contact Center. From this Interaction record, you can then create child records to capture and address inquiries and record reported Adverse Events and Product Quality Complaints. An Interaction can have more than one child record of the same type.

To make it easier for users to record and manage medical information inquiries, you can expose and arrange Inquiry Management components on the primary objects' record pages.

Interaction​

An Interaction record stores information from the communication between an agent at a contact center and the Requester or Referred By person who contacted the contact center.

Interaction is the central object of Inquiry Management. It is the Salesforce Case object relabeled as Interaction. As a result, you will see references to the Case object in code and declarative configuration throughout the Inquiry Management module.

Request​

A Request is a child record of an Interaction. Each Request stores information about the account's inquiry and any responses that have been provided. There can be multiple Requests in a single Interaction. For example, if a Health Care Provider asks three questions on a call, you will create a single Interaction and three Request records underneath that Interaction.

Fulfillment​

A Fulfillment record is a child record of an Interaction. From a Fulfillment record, you can create a package of information to send via email, mail, or fax to the Account that submitted the inquiry. A Fulfillment Package includes:

  • A cover letter, which lists the full content of the Fulfillment Package and any warnings/disclaimers

  • Documents from your Content Management System

  • Non-Standard Response documents that have been uploaded to the Request(s).

Inquiry Management uses Dynamic Document Packages to generate Fulfillment Packages.

When you give an Account a verbal response, you do not create a Fulfillment. Fulfillments are only used for written responses.

Adverse Event​

An Adverse Event record is a child record of an Interaction. With an Adverse Event record, you can capture and store information on perceived unintended or unfavorable symptoms of a product. Adverse Events can be packaged as a PDF and emailed out.

Product Quality Complaint​

A Product Quality Complaint record is a child record of an Interaction. With a Product Quality Complaint record, you can capture and store information related to a potential product quality issue. Issues may be related to manufacturing, stability and release testing, dose preparation, storage, or distribution. Product Quality Complaints can be packaged as a PDF and emailed out.

Home Page​

Medical Information Agents, Supervisors, and QA Users see a country-specific, consolidated, home-page dashboard that:

  • displays all items that might need action or attention.

  • gives users a sense of the overall amount of work that needs to be done within their area.

To view the Home Page, select Home from the Navigation Menu.

Home Page components​

The Home Page consists of a set of standard Salesforce components, shown below.

  • New Interactions Queue - shows any newly assigned or created interactions for the logged-in user. Users can also create new Interactions from this section by clicking New in the top right corner of the section.

  • My Interactions - Open - shows the logged-in user's open interactions. New Interactions can also be created from this section by clicking New in the top right of the section's highlight panel.

  • My Open Requests - shows a list of the user's open requests with a snapshot of relevant information including:

    • Request number

    • Product name

    • Content of the request (truncated for length)

    • Alerts flag

    • Due date

    Users can click More in the top right of the section to go to their Requests page.

  • My AEs Pending Submission - shows pending AE submissions. Users can click More in the top right corner to view their Adverse Events page.

  • My PQCs Pending Submission - shows pending PQC submissions. Users can click More in the top right corner to view their Product Quality Complaint page.

Interactions​

An Interaction is the central object of Inquiry Management and is the starting point for agents. The Interaction is a Salesforce "Case", just relabeled. For that reason, you will see references to the Case object in code and declarative configuration throughout the Inquiry Management module.

Interaction components​

Inquiry Management makes heavy use of the Salesforce Service Cloud Console and has been configured to display multiple Lightning components.

You can expose and arrange components on the Lightning record pages to make it easier for users to record and manage medical information inquiries and meet business requirements. The Lightning record components table below lists the available components in the Inquiry Management system.

Lightning record components​
Component labelDescription
Field Audit Trail Related ListField Audit Trail Related List is a Lightning component that displays field-level change tracking information for a record. The displayed information is an aggregate view of audit trail events from three sources: - Salesforce's Shield's Field Audit Trail - Salesforce's normal field history tracking - Inquiry Management Field Audit Trail
MIC - Case AccountsThe MIC - Case Accounts component enables users to search for and associate a Requester, Referred by, or Institution account with an Interaction.
MIC - Enhanced Record EditThe MIC - Enhanced Record Edit component always displays fields in an editable format and auto-saves entered field data.
MIC - HELPER: Workspace API HelperAllows the Salesforce console workspace API access for Lightning Web Components.
MIC - NotepadThe MIC - Notepad component enables users to immediately enter inline notes from an Interaction and create new notes. All notes are auto-saved. When multiple notes exist for an Interaction, the component displays the most recently modified note.
MIC - Related ListThe MIC - Related List component displays Request, Fulfillment, Adverse Event, Product Quality Complaint, and Interaction QA records related to a given Interaction and enables users to create new related records. While similar to the standard Salesforce Related List - Single component, the MIC - Related List component requires fewer clicks to create new related records, displays related records in a more compact, table grid-view, and includes more configuration points than the Related List - Single component.
MIC - Console ConfigThe MIC - Console Config component displays the value of a specified formula field as a workspace's tab label.
MIC - SObject Record Edit ViewThe MIC - SObject Record Edit View is a Lightning Web Component that displays fields on Lightning record pages in a simple edit view with a Save button that is always in Edit mode.
MIC - SObject Record Read ViewThe MIC - SObject Record Read View is used to put arbitrary read-only fields into a Lightning record page.

Requests​

A Request is a child record of an Interaction. Each Request stores information about the account's inquiry and any responses that have been provided. There can be multiple Requests in a single Interaction. For example, if an HCP asks multiple questions in a single email or conversation, each question will have its own Request within a single Interaction.

Request view​

Besides the standard fields, the Request page layout also has embedded components in it. These components include:

Enhanced Record Edit​

Requests can be edited as needed, with any changes automatically saved using the Enhanced Record Edit component. Visit the Enhanced Record Edit topic for more information.

Product Lookup​

The Product Lookup Lightning component enables users to search the product database and select a product value for MED_Product__c.

Each product result contains the name of the product and a subtitle. The subtitle is comprised of product metadata separated by the "•" character.

Visit Product Lookup for more information.

Request Content Search​

The MIC - Request Content Search component adds a search bar and button to the default Request Record page. The search bar and button launch a search modal and immediately execute the search. From the modal, you can filter results, refine your search, attach documents to the Request record, and preview a document search result in a modal with the document viewer.

Visit Request Content Search for more information and configuration instructions.

Interaction Follow-ups​

You can create a Follow-up Interaction and associated Request to communicate content updates to requesters who have given consent to receive them using one of the methods below.

To record a requester's consent using the Edit icon:

  1. In an open Request, click the Follow-Up tab.

  2. Click the Edit icon in the Requester Consent field.

  3. Check the box in the Requester Consent field to indicate their consent.

  4. Complete the following fields, if applicable:

    • Consent Expiry Date

    • Target Follow-up Date

    • Opt-Out Date

    • Eligible for Follow-up

    • Follow-up Reason

  5. Click Save.

To record a requester's consent using the Update Follow-up Consent Details quick action button:

  1. In an open Request, click the dropdown arrow in the top right of the Request section.

  2. Select Update Follow-up Consent Details.

  3. Use the Update Follow-up Consent Details modal to record the relevant requester consent details.

  4. Click Save.

Note: You can use the Update Follow-up Consent Details quick action button if the request is open or closed. However, once the request is closed, you can only use the quick action button to update consent information.

To record a requester's consent on fulfillment, visit the Configure follow-up opt in/opt out emails section. You can use the fulfillment email templates that are provided out-of-the-box and configure them so that requesters can either opt in or out of receiving updates.

Adding a Follow-up Interaction to a Request​

To add a Follow-up Interaction to a Request:

  1. In an open Request, click the dropdown menu in the top right of the Request's highlight panel.

  2. Select Follow-up Request. The Follow-up Request modal appears.

  3. To copy content from the content repository, click the Copy Response Content checkbox. Otherwise, leave it unchecked.

  4. Click Create. You are automatically brought to the new Request page within the new Interaction.

The new Interaction is created with the following values pre-populated:

  • Channel = Follow-up

  • Follow-up To = Original Interaction from which the Interaction was created

  • Status = Open

The new Request is created with the following values pre-populated:

  • Interaction number

  • Owner

The new Request has the following values removed:

  • Date Opened

  • Date Closed

  • Due Date

Note: A request created by a Follow-up cannot be created from a request that is also a Follow-up. For requests that were made from a Follow-up, the contents of the Follow-up tab will not appear since the consent was recorded in the original request.

Cloning a Request​

Previously created Requests can be cloned and associated with new Interactions. This helps facilitate an easier workflow by reusing commonly used question and answer content.

To clone a Request:

  1. From a Request, click the dropdown caret in the top right and select Clone Request.

  2. On the Clone Request modal, either keep the pre-populated Interaction in the Parent Interaction field or search for and select a different one.

  3. Check the checkbox next to Copy Response Content to copy the content into the cloned request.

  4. Click Clone.

Once cloned, the system will automatically:

  • Put the cloned request in "Open" status.

  • Clear any related Inbound Form lookups (if applicable).

  • Automatically update the Cloned From field with the record from which the new record was cloned.

Configuring the Follow up tab on a Request record​

You can enable your users to capture consent details as part of a broader workflow. Using the steps below, you can allow them to capture consent from a requester to follow up with more information at a later date.

To configure the Follow-up tab on a Request record:

  1. From Setup, click the Object Manager tab.

  2. Search for and select the Interaction (Case) object.

  3. Click Fields & Relationships.

  4. Select the Channel field and add 'Follow-up' as a picklist value.

  5. From Setup, click the Object Manager tab.

  6. Search for and select the Request (MED__Request__c) custom object.

  7. Click Lightning Record Pages on the left side navigation panel.

  8. Click Request.

  9. Click Edit. The Lightning App Builder appears for the Request page.

  10. Select the Follow-up tab.

  11. Click the Fields tab on the navigation panel on the left side of the page.

  12. Under the Fields Component section, click and drag Field Section, and drop it onto the Follow-up section.

  13. Under the Fields section on the navigation panel on the left side of the page, click, drag, and drop the following fields:

    • Requester Consent

    • Consent Expiry Date

    • Target Follow-up Date

    • Opt-Out Date

    • Eligible for Follow-up

    • Follow-up Reason

  14. Click the Requester Consent section you just created. On the right side of the page, enter "Requester Consent" in the Label field.

  15. Click Save.

Configuring the Follow-up Action on a Request​

You can enable your users to create a Follow-up Interaction and associated Request as part of a broader workflow. This workflow would allow them to capture consent from a Requester to follow-up with more information at a later date, or simply associate a new Request with a previously relevant interaction using the methods below.

To configure the follow-up action on a request:

  1. From the Request page in the Lightning App Builder, click the highlights panel.

  2. On the right side of the page, under Actions, click Add Action. A search modal appears.

  3. Search for and select Follow-up Request and click Done. It now appears under the list of actions.

  4. Click the new Follow-up Request action and drag it to the appropriate position.

  5. Click Save.

Custom Objects​

Request - The Request object stores information about medical inquiries and the provided responses.

Create custom responses and FAQs from requests​

You can create custom responses and FAQs via quick actions by clicking on New Custom Response or New FAQ in a given Request record. Doing so opens up a document creation wizard modal that is pre-populated with data from the Request record or its parent Interaction object to reduce manual data entry. The modal also lets you complete and confirm any required or additional information.

You can also create custom responses by clicking on New Custom Response in the search modal that opens via the Request Content Search component. Once a new custom response is reviewed and has a status of Approved, it will appear in search results going forward. For more information about Custom Responses, refer to Custom Responses.

Note: Only users assigned to the CM_ContentAuthor Permission Set can use this feature.

Enable functionality​

To enable this functionality for users:

  1. Open the relevant Request record page in the Lightning App Builder.

  2. Drag and drop the MIC -- Document Wizard Modal (medDocumentWizard) hidden helper component onto the page.

  3. Click on the Highlights Panel component, and add the New Custom Response and New FAQ actions.

    For each action, you can add a filter to ensure that only users with the correct permissions can view and use the feature. To add a filter:

    1. Click Add Filter.

    2. Click Advanced.

    3. Set the Field to Permissions > Custom Permissions > CM_User.

    4. Set the Operator to Equal.

    5. Set the Value to True.

    6. Click Done.

    ::: :::

Note: To add actions to the Highlights Panel component via the Lightning App Builder, Dynamic Actions must be enabled.

  1. Click on the Request Content Search component, and check the Allow Document Creation checkbox. This lets users create custom responses from the Search Content component as well.

  2. Click Save.

Configure modal​

To modify the pre-populated Document Type and Document Subtype fields in the modal, modify the Document Type (mvn__MED_Document_Type__c) and Document Subtype (mvn__MED_Document_Subtype__c) fields for these existing Document Wizard Settings (mvn__MED_Document_Wizard_Settings__mdt) records:

Document Wizard Settings records​
LabelAPI name
Request - Custom ResponseMED_Request_Custom_Response
Request - FAQMED_Request_FAQ

Warning: Do not modify the API names of the Document Wizard Settings records listed in the Document Wizard Settings records table.

To configure the layout of the document creation wizard modal and output, refer to Layout locations.

Adverse Events​

An Adverse Event (AE) record stores information on perceived unintended or unfavorable symptoms of a product. An AE record can be added to an Interaction to track pertinent information. The AE page is configured using the Adverse Event Layout (MED_Adverse_Event_Layout__mdt) custom metadata type and uses the following custom objects:

Adverse Event primary sources​

When the Auto Stamp Primary Source Global Setting is enabled and an Adverse Event record is created, Medical Information Cloud automatically creates and displays primary source records in the AE Primary Source Related List on the Adverse Event record. The primary source records automatically populate with information from the Requester and Referred By accounts listed on the Interaction. More specifically, information about the Requester listed on Interaction maps to an automatically generated primary source record associated with the Adverse Event. Likewise, Referred By fields on the Interaction map to a second primary source record. For more information about the Global Setting custom metadata, see Custom metadata settings.

Field mappings​

The Requester to primary source field mapping and Referred By to primary source field mapping tables list the primary source field mappings.

Requester to primary source field mapping​
AE Primary SourceCase
MED_First_Name__cAccount.FirstName
MED_Last_Name__cAccount.LastName
MED_Middle_Name__cAccount.MiddleName
MED_Title__cAccount.PersonTitle
MED_Qualification__cAccount.MED_Credentials__c
MED_Organization__cMED_Institution_Name__c
MED_City__cMED_City__c
MED_Postal_Code__cMED_Postal_Code__c
MED_Phone__cMED_Phone__c
MED_State__cMED_State__c
MED_Country__cMED_Country__c
MED_Address_Street__cMED_Address_Line_1__c + MED_Address_Line_2__c :::: note ::: title ::: If the Case street address value exceeds 100 characters, the value is truncated when mapped to MED_Address_Street__c. ::::

In the Referred By to primary source field mapping table, sometimes the Case fields lead with <primary address> or <primary phone>. <primary address> and <primary phone> indicate that the data is copied from the Contact Information records related to the Referred By Account.

Note: Account type MED_Employee is blacklisted from creating a primary source from Referred By.

Referred By to primary source field mapping​
AE Primary SourceCase
MED_First_Name__cMED_Referred_By__r.FirstName
MED_Last_Name__cMED_Referred_By__r.LastName
MED_Middle_Name__cMED_Referred_By__r.MiddleName
MED_Title__cMED_Referred_By__r.PersonTitle
MED_Qualification__cMED_Referred_By__r.MED_Credentials__c
MED_City__c<primary address>.MED_City__c
MED_Postal_Code__c<primary address>.MED_Postal_Code__c
MED_Phone__c<primary phone>.MED_Phone__c
MED_State__c<primary address>.MED_State__c
MED_Country__c<primary address>.MED_Country__c
MED_Address_Street__c<primary address>.MED_Address_Line_1__c + MED_Address_Line_2__c :::: note ::: title ::: If the Case street address value exceeds 100 characters, the value is truncated when mapped to MED_Address_Street__c. ::::

E2B(R3) generation​

E2B(R3) XML files can be generated from and attached to an Adverse Event (MED_Adverse_Event__c) record. They are attached as Files or as Attachments depending on the "Use Files" Global Setting value configured within the instance.

The following file formats are supported:

  • Portable network graphics (.png)

  • Bitmap image format (.bmp)

  • Graphics interchange format (.gif)

  • Word processing document format (.wpd)

For additional details regarding the E2B(R3) support, see E2B(R3) support.

Enablement​

To enable the ability for users to generate E2B files, add add the Generate E2B quick action to the Adverse Event page layout.

Configuration​

Medical Information Cloud ships with a default mapping of Adverse Event (and child object) fields to nodes in the E2B(R3) XML specification. These mappings can be modified using the E2B Field Mapping and E2B Setting custom metadata types. The field mapping maps the Data Element Identifiers (e.g., C.1.2) to fields in the data model. Currently, only data elements with a default mapping are supported in the output E2B file.

If Medical Information Cloud is configured to use Salesforce Files instead of attachments, additional documents attached to the Adverse Event are also included in the E2B file.

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
1MED_E2B_Download_Button
2MED_E2B_Error
3MED_E2B_Error_Header
4MED_E2B_Field_Required
5MED_E2B_Generate_Button
6MED_E2B_Generator_Header
7MED_E2B_Generator_Instruction_Text
8MED_E2B_Invalid_Document_Format
9MED_E2B_Locked_Message
10MED_E2B_Success

Customization​

Customers can override how E2B XML documents are generated through the use of the E2B customization framework. This framework is intended to be utilized by a Salesforce.com developer to alter how E2B XML files are generated. This can be useful should an XML element attribute require a localized value that differs from the standard XML schema that is supported.

The high-level process of customizing an XML node generation is as follows:

  1. Review the documentation within the MED_E2B_MCCI_IN200100UV01_Batch apex class within the source code.

  2. Create a new Apex Class that extends the MED_E2B_MCCI_IN200100UV01_Batch apex class, and implement the desired implementations of the relevant virtual methods from the MED_E2B_MCCI_IN200100UV01_Batch class. As a best practice appropriate test code should also be written to offer unit test coverage for the customization.

  3. Deploy the new Apex Class to the appropriate environments.

  4. Create an E2B Custom Generator Custom Metadata Type to register the new Apex Class with the E2B generation process.

  5. Test the custom functionality by generating test E2B documents.

For developers seeking to customize how an XML element within the E2B file is generated, visit How to Contact Customer Support to contact Customer Support for sample code and additional developer details.

Telecom tags​

By default, \<telecom\> tags in E2B files automatically add the appropriate telecommunication prefix for every reporter's phone number, sender's phone number, sender's fax number, and sender's email address, if a prefix does not already exist. The \<telecom\> tag prefixes are as follows:

Element numberElement name\<telecom\> tag prefix
C.2.r.2.7Reporter's Telephonetel:
C.3.4.6Sender's Telephonetel:
C.3.4.7Sender's Faxfax:
C.3.4.8Sender's Emailmailto:

NullFlavors​

As a general rule, Medical Information Cloud omits the node instead of using a nullFlavor. For example, if a field does not have a value, it is not included and nullFlavor is not used. When D.1, specifically, is left blank, they will be sent as a nullFlavor of UNK.

To set a nullFlavor, map a value with nullFlavor_\<null flavor value\>. The specified \<null flavor value\> (without the nullFlavor_ prefix) will be set as a special nullFlavor attribute.

Integration​

Customers that intend to integrate generated E2B files with 3rd party systems are recommended to explore facilitation via an integration service provider. The Salesforce.com platform is optimized to support multi-tenancy, which includes limits placed on the amount of computing resources any one tenant can consume from shared platform resources. Specifically, there exist several limits on the size and duration of outbound HTTP/S requests that can be made natively on the Salesforce.com platform.

Given the nature of E2B files and the potentially large number and large size of related source materials, it is recommended that Customers use an external integration solution, such as a middleware provider, to ensure E2B files are transmitted in a reliable and scalable fashion.

For more information on the relevant platform governor limits, see Salesforce's documentation.

E2B(R3) support​

Medical Information Cloud can now generate E2B files that comply with the R3 specification, available here: https://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM275638.pdf

It should be noted that not all elements supported within the comprehensive E2B(R3) specification are supported currently. While efforts have been made to cover the portions of the specification most relevant to medical information, there may exist certain scenarios that are not presently covered. For this reason, it is highly recommended that sufficient time be allocated to properly define the requirements specific to a particular implementation of E2B within and rationalize them against the supported field set to ensure no gaps exist. Fields that are not explicitly listed below should be considered unsupported.

Supported E2B(R3) elements​

The current set of E2B(R3) elements supported within is defined in the tables below.

Case safety report elements​
Element numberElement name
C.1.3Type of Report
C.1.4Date Report Was First Received from Source
C.1.6.1Are Additional Documents Available
C.1.6.1.r.1Documents Held by Sender
C.1.7Does This Case Fulfill the Local Criteria for an Expedited Report?
C.2.r.1.1Reporter's Title
C.2.r.1.2Reporter's Given Name
C.2.r.1.3Reporter's Middle Name
C.2.r.1.4Reporter's Family Name
C.2.r.2.1Reporter's Organization
C.2.r.2.2Reporter's Department
C.2.r.2.3Reporter's Street
C.2.r.2.4Reporter's City
C.2.r.2.5Reporter's State or Province
C.2.r.2.6Reporter's Postcode
C.2.r.2.7Reporter's Telephone
C.2.r.3Reporter's Country Code
C.2.r.4Qualification
C.2.r.5Primary Source for Regulatory Purposes
C.4.r.1Literature Reference(s)
C.5.3Sponsor Study Number
C.5.4Study Type Where Reaction(s) / Event(s) Were Observed
Patient elements​
Element numberElement name
D.1Patient (name or initials)
D.2.1Date of Birth
D.2.2.1aGestation Period When Reaction / Event Was Observed in the Foetus (value)
D.2.2.1bGestation Period When Reaction / Event Was Observed in the Foetus (unit)
D.2.3Patient Age Group (as per reporter)
D.3Body Weight (kg)
D.4Height (cm)
D.5Sex
D.6Las Menstrual Period Date
D.7.1.r.1aMedDRA Version for Medical History
D.7.1.r.1bMedical history (disease / surgical procedure / etc.) (MedDRA code)
D.7.1.r.2Start Date
D.7.1.r.3Continuing
D.7.1.r.4End Date
D.7.1.r.5Comments
D.7.1.r.6Family History
D.7.2Text for Relevant Medical History and Concurrent Conditions (not including reaction / event)
D.7.3Concomitant Therapies
D.8.r.1Name of Drug as Reported
D.8.r.4Start Date
D.8.r.5End Date
D.8.r.6aMedDRA Version for Indication
D.8.r.6bIndication (MedDRA code)
D.8.r.7aMedDRA Version for Reaction
D.8.r.7bReaction (MedDRA code)
D.9.1Date of Death
D.9.2.r.1aMedDRA Version for Reported Cause(s) of Death
D.9.2.r.1bReported Cause(s) of Death (MedDRA code)
D.9.2.r.2Reported Cause(s) of Death (free text)
D.9.3Was Autopsy Done?
D.9.4.r.1aMedDRA Version for Autopsy-determined Cause(s) of Death
D.9.4.r.2Autopsy-determined Cause(s) of Death (free text)
D.10.1Patient Identification
D.10.2.1Date of Birth of Parent
D.10.2.2aAge of Parent (number)
D.10.3Last Menstrual Period Date of Parent
D.10.4Body Weight (kg) of Parent
D.10.5Height (cm) of Parent
D.10.6Sex of Parent
D.10.7.1.r.1aMedDRA Version for Medical History
D.10.7.1.r.1bMedical History (disease / surgical procedure/ etc.) (MedDRA code)
D.10.7.1.r.2Start Date
D.10.7.1.r.3Continuing
D.10.7.1.r.4End Date
D.10.7.1.r.5Comments
D.10.7.2Text for Relevant Medical History and Concurrent Conditions of Parent
D.10.8.r.1Name of Drug as Reported
D.10.8.r.4Start Date
D.10.8.r.5End Date
D.10.8.r.6aMedDRA Version for Indication
D.10.8.r.6bIndication (MedDRA code)
D.10.8.r.7aMedDRA Version for Reaction
D.10.8.r.7bReactions (MedDRA code)
Reaction / Event elements​
Element numberElement name
E.i.1.1aReaction / Event as Reported by the Primary Source in Native Language
E.i.1.1bReaction / Event as Reported by the Primary Source Language
E.i.1.2Reaction / Event as Reported by the Primary Source for Translation
E.i.2.1aMedDRA Version for Reaction / Event
E.i.2.1bReaction / Event (MedDRA code)
E.i.3.1Term Highlighted by the Reporter
E.i.3.2aResults in Death
E.i.3.2bLife Threatening
E.i.3.2cCaused / Prolonged Hospitalisation
E.i.3.2dDisabling / Incapacitating
E.i.3.2eCongenital Anomaly / Birth Defect
E.i.3.2fOther Medically Important Condition
E.i.4Date of Start of Reaction / Event
E.i.5Date of End of Reaction / Event
E.i.6aDuration of Reaction / Event (number)
E.i.6bDuration of Reaction / Event (unit)
E.i.7Outcome of Reaction / Event at the Time of Last Observation
E.i.8Medical Confirmation by Healthcare Professional
E.i.9Identification of the Country Where the Reaction / Event Occurred
Test result elements​
Element numberElement name
F.r.1Test Date
F.r.2.1Test Name (Free text)
F.r.2.2aMedDRA Version for Test Name
F.r.2.2bTest Name (MedDRA code)
F.r.3.1Test Result (code)
F.r.3.2Test Result (value / qualifier)
F.r.3.3Test Result (unit)
F.r.3.4Result Unstructured Data (free text)
F.r.4Normal Low Value :::: note ::: title ::: Enter numeric values for the units described in MED_Unit__c. Numeric values improve reporting per the E2B(R3) specification. ::::
F.r.5Normal High Value :::: note ::: title ::: Enter numeric values for the units described in MED_Unit__c. Numeric values improve reporting per the E2B(R3) specification. ::::
F.r.6Comments (free text)
F.r.7More Information Available
Drug elements​
Element numberElement name
G.k.1Characterization of Drug Role
G.k.2.2Medicinal Product Name as Reported by the Primary Source
G.k.2.4Identification of the Country Where the Drug Was Obtained
G.k.3.1Authorization / Application Number
G.k.3.2Country of Authorization / Application
G.k.3.3Name of Holder / Applicant
G.k.4.r.1aDose(number)
G.k.4.r.1bDose (unit)
G.k.4.r.2Number of Units in the Interval
G.k.4.r.3Definition of the Time Interval Unit
G.k.4.r.4Date and Time of Start of Drug
G.k.4.r.5Date and Time of Last Administration
G.k.4.r.6aDuration of Drug Administration (number)
G.k.4.r.6bDuration of Drug Administration (unit)
G.k.4.r.7Batch / Lot Number
G.k.4.r.8Dosage Text
G.k.4.r.9.1Pharmaceutical Dose Form (free text)
G.k.4.r.10.1Route of Administration (free text)
G.k.4.r.10.2aRoute of Administration TermID Version Date / Number
G.k.4.r.10.2bRoute of Administration TermID
G.k.4.r.11.1Parent Route of Administration (free text)
G.k.4.r.11.2aParent Route of Administration TermID Version Date / Number
G.k.4.r.11.2bParent Route of Administration TermID
G.k.5aCumulative Dose to First Reaction (number)
G.k.5bCumulative Dose to First Reaction (unit)
G.k.6aGestation Period at Time of Exposure (number)
G.k.6bGestation Period at Time of Exposure (unit)
G.k.7.r.1Indication as Reported by the Primary Source
G.k.7.r.2aMedDRA Version for Indication
G.k.8Action(s) Taken with Drug
G.k.9.i.3.1aTime Interval between Beginning of Drug Administration and Start of Reaction / Event (number)
G.k.9.i.3.1bTime Interval between Beginning of Drug Administration and Start of Reaction / Event (unit)
G.k.9.i.3.2aTime Interval between Last Dose of Drug and Start of Reaction / Event (number)
G.k.9.i.3.2bTime Interval between Last Dose of Drug and Start of Reaction / Event (unit)
G.k.9.i.4Did Reaction Recur on Re-administration?
G.k.11Additional Information on Drug (free text)
Case summary elements​
Element numberElement name
H.1Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and Additional Relevant Information
H.2Reporter's Comments
Transmission identification elements​
Element numberElement name
N.1.3Batch Sender Identifier
N.1.4Batch Receiver Identifier
N.2.r.2Message Sender Identifier
N.2.r.3Message Receiver Identifier
Document attachments​

Optionally, you can configure whether or not you want documents compressed and included in the E2B file. This can be enabled for any attachments that are included in-line within the E2B file. supports the deflate compression algorithm. For additional details on this configuration, see E2B(R3) support.

To enable file compression:

  • If you are including files, ensure the Use Compression (MED_Use_Compression__c) field on the E2B Setting (MED_E2B_Setting__mdt) custom metadata type is checked.

  • If the files attached to the E2B should be included in the E2B XML file, ensure the Include Files (MED_Include_Files__c) field on the E2B Setting (MED_E2B_Setting__mdt) is checked.

As of V15, the new E2B package, the E2B XML is now always stored as a Salesforce file and never as an attachment as the MED_Global_Settings__.MED_Use_Files__c metadata is no longer supported. As such, you still need to configure these settings for the new E2B package. Reference the Required actions section below.

Required actions​

If using the new E2B package, you must complete the following required actions:

  1. Assign the new MED_E2B_User permission set to users who need to generate E2B files. If using permission set groups, as recommended, add this new permission set to the existing group that is assigned to your users.

  2. Make sure MED_E2B_Setting__mdt.MED_Include_Files__c is checked unless MED_Global_Settings__.MED_Use_Files__c was unchecked (rare). The former controls whether files are included in the XML output.

E2B testing​

Medical Information Cloud uses the following procedures when validating E2B functionalities.

E2B development and bug fixing​

When developing or fixing the E2B generation, developers should reference this information and use the following testing strategies.

  • Manually check the XML file for the values entered into the AE (Adverse Event)

  • Compare the XML structure to the reference instance

  • Perform E2B Schema validation with xmllint

  • Perform FDA validation with FDA online validator

  • XPath validation

Validation testing​

Validation test cases require manually filling out a specific set of fields, generating the file, and verifying the values are present. While not every field is tested individually, all supported fields are included in the overall testing. Additionally, some tests involve populating a large number of fields then validating the file using the FDA validator.

Each bug identified also has a dedicated test case to replicate the exact scenario of the bug and manually confirm that the XML meets the expected format. Moving forward, will also be adding XPath validation to all new bug fix validation tests.

  • For Ad-hoc testing when developers make a change, the following processes are followed:

    • Use a tool to randomly populate a complete Adverse Event, generate the E2B then check it against the XML Schema using xmllint

    • Perform FDA validation steps

    • Compare the test case to the reference instance

  • For Existing test plans:

    • Most test cases manually check for the values

    • There is a generic case that uses xmllint to validate the entire file

  • For New bugs have a dedicated test plan that includes the following:

    • Conducting FDA validation

    • Performing XPath validation

      • The XPath and version used will be published

Fulfillment​

A record that stores the written response you send via email, fax, or mail to an Account. With a Fulfillment record, you can create a package of information to send via email, mail, or fax to the account that submitted the inquiry. The Fulfillment Package includes a cover letter and all the documents used to answer the account's questions.

When you give an Account a verbal response, you do not create a Fulfillment. Fulfillments are only used for written responses.

A Fulfillment record can be configured using the Fulfillment (MED_Fulfillment__c) custom object.

Fulfillment package generation​

A fulfillment is a document or a collection of documents that is sent to a requester via channels like email, mail, chat, fax, and in-person delivery to address some question or concern and resolve the medical information request captured in the system. To generate and send fulfillment packages, Medical Information Cloud first uses Nintex's DocGen service to assemble all of the selected or configured content elements as a Dynamic Document Package (DDP) onto a Fulfillment (MED_Fulfillment__c) record and then lets users choose how to deliver the package to fulfill the request. For email deliveries, the system has two methods: an Email Fulfillment option and a Digital Fulfillment option. The former takes users directly to the email message with the fulfillment package attached, where the email message uses predefined Classic Email Templates as configured on the DocGen Package's Email Delivery Option. The latter, on the other hand, allows users to construct a dynamic email template from content elements that exist within the Inquiry Management module. For more information on how to generate and send fulfillment packages, reference the Generate packages and Enable the package generation functionality sections below.

Warning: To generate and send fulfillment packages, users must be assigned the DocGen User (DDP_User_All) permission set, which is included in the User (MED_Medical_Information_Cloud_User) permission set group. To customize the cover letter component and email body message, users must also be assigned the Customize Response on Fulfillment (MED_Customize_Response_on_Fulfillment) custom permission.

Generate packages​

The fulfillment package generation process involves creating a cover letter, which merges all of the related cover letter component documents with the relevant request and case documents, generating the merged fulfillment package document, and then attaching the fulfillment package as a file on a Fulfillment record, along with any request documents whose delivery option equals Attach Separate, PDF or Attach Separate, Original Format. The package generation functionality must be enabled according to the Enable the package generation functionality section while the components to be included inside the cover letter and the documents to be merged into the package can be configured according to the Configure cover letter component behavior and Configure which cover letter components to merge sections.

After the package generation functionality is properly enabled and configured, users can initiate the fulfillment package generation process by clicking the Generate Package button on a Fulfillment record page. This will open the Configure Fulfillment Package modal for users to modify and confirm both the contents to be included in the different sections of the cover letter as well as any documents to be merged based on their individual delivery options. If there are multiple pieces of information within a section in the cover letter, users can drag and drop the information to reorder how they appear in the cover letter.

The Configure Fulfillment Package modal also lets users choose between two delivery methods. If a user selects Finalize, the package generation job will create a single, compliant PDF file that is automatically attached to the Fulfillment record. On the other hand, if a user selects Customize, the package generation job will instead create a DOCX file for the user to further refine before finalizing as a PDF file.

To actually run the package generation job, users must click Run in the Configure Fulfillment Package modal. Afterwards, users can track the progress of the job with the Running Jobs utility bar at the bottom of the page, which can be minimized or kept open throughout the process.

When the fulfillment package finishes generating or if the package generation process runs into an error, users are notified in the Running Jobs utility bar and via the bell notification at the top of the page. If the fulfillment package is generated successfully, a link to the Fulfillment record will be available and users can subsequently choose how to deliver the fulfillment package to the requester. For email deliveries, there are two ways to send the fulfillment package, as described in the Send fulfillment packages via email section below. If the fulfillment package does not generate successfully, however, please reference the Troubleshoot Nintex errors section below. Once the Fulfillment record is closed or canceled, the package job will no longer appear in the Running Jobs utility bar.

Configure Fulfillment Package modal options ::: {wrapper="1" role="img-thumbnail"} :::Running Jobs utility bar ::: {wrapper="1" role="img-thumbnail"} :::
Enable the package generation functionality​

To enable the fulfillment package generation functionality:

  1. Add the Generate Package (MED_Generate_Fulfillment_Package) button to the appropriate Fulfillment page layout. For information on how to add buttons to page layouts, visit Salesforce's documentation on how to Define Custom Buttons and Links.

  2. Add the MIC - Nintex Queue (MED_NintexQueue) utility bar component to the app and set the component to run automatically. For more information about the utility bar in Medical Information Cloud, visit Utility bar.

Warning: The fulfillment package generation process will not run unless the component is visible in the active app.

  1. In Setup, search for and select App Manager.

  2. To the right of the MIC (Medical_Information_Cloud) app, click the dropdown arrow and then Edit.

  3. Click Utility Items (Desktop Only).

  4. Ensure that the MIC - Nintex Queue (MED_NintexQueue) component is in the utility bar. If it is not, click Add Utility Items and then MIC - Nintex Queue.

    1. (Optional) Rename the label of the component from "MIC - Nintex Queue" to "Running Jobs".

  5. Ensure that the MIC - Nintex Queue component is set to start automatically. If it is not, check Start automatically.

  6. Click Save.

Load default DDPs​

Dynamic DocGen Packages (DDPs) are used to generate fulfillment packages as well as to create snapshots of Medical Information Cloud records, enabling the Generate Package, Generate Snapshot, and Send to Safety buttons on Fulfillment (MED_Fulfillment__c), Request (MED_Request__c), and Adverse Event (MED_Adverse_Event__c) record pages, respectively. You can choose to either use 's default DDPs, modify them, or create your own. The Package Job (mvn__MED_Package_Job__c) object facilitates the processing of DDPs.

To load the default Medical Information Cloud DDPs into your Salesforce environments with the Install Service, install the Medical Information Cloud - Setup configuration and run the optional "Load default DDPs and enable files" step.

Note: The standard Generate Package, Generate Snapshot, and Send to Safety buttons in Medical Information Cloud are object links with URL parameters that contain specific DDP tags. For instance, the filter parameter is the specific tag that the system needs in order to know which DDP to use.

If you are modifying or creating your own DDPs, you can include record data using merge field notation. This will enable you to configure dynamic delivery options under different criteria. For example, if you set the filter parameter in the URL so that it equals REQSnapshotDDP_ plus the 2-digit ISO country code, then the filter for requests in the United States would look like REQSnapshotDDP_US. However, keep in mind that if you update the parameters in the URL to use a dynamic value and there is no DDP with a matching filter value, then the system will fail to generate the DDP.

For more information about object links and merge fields, reference Salesforce's documentation on how to Provide Actions, Buttons, and Links and Merge Fields, respectively.

Configure cover letter component behavior​

To identify which content elements can be included in the cover letter of a fulfillment package, such that they can be selected and organized in the Configure Fulfillment Package modal, use the Dynamic Fulfillment Setting (MED_Dynamic_Fulfillment_Setting__mdt) custom metadata type. Each Dynamic Fulfillment Setting metadata record represents a collection of settings that define how the cover letter components should be merged into the cover letter. First, the Subtype (MED_Document_Subtype__c) field determines which Document (mvn__CM_Document__c) record(s) the information should be retrieved from. Then, the other Dynamic Fulfillment Setting metadata fields specify which cover letter components are optional or required, what default values should be set for certain components, what order or what section each piece of information should appear in the cover letter and modal, how the selected components should be combined, and more.

Configure which cover letter components to merge​

To configure the optional, conditional criteria that determine which cover letter components should be merged into a fulfillment package, use the Dynamic Fulfillment Filter (MED_Dynamic_Fulfillment_Filter__mdt) custom metadata type. Each Dynamic Fulfillment Filter metadata record represents some criteria for filtering cover letter components by matching the configured Fulfillment Field (MED_Fulfillment_Field__c) value to the corresponding Document Field (MED_Document_Field__c) value. For example, if a typical fulfillment package needs a specific indication statement to apply for a healthcare professional versus a consumer, you may wish to create a Dynamic Fulfillment Filter metadata record related to a Dynamic Fulfillment Setting metadata record for indication cover letter components. On the Dynamic Fulfillment Filter metadata record, the Fulfillment Field value on the former can be set to equal a custom formula field called Account_Type__c that retrieves the Account record type (MED_Account__r.MED_Record_Type_Name__c) value while the Document Field value would relate to the MED Allowed Audience (MED_Allowed_Audience__c) CMS Field Mapping (MED_Document_Field_Mapping__mdt) metadata record. After the filtered components are retrieved, they are displayed in the Generate Fulfillment Package modal and are available to be merged into the fulfillment package in place of all of the cover letter components of that subtype.

Configure documents to merge​

To configure how a document in the Inquiry Management module behaves during the fulfillment package generation process, modify the document's metadata. Specifically, the Delivery Option (mvn__CM_Delivery_Option__c) field on the Document Version (mvn__CM_Document_Version__c) object, which is a required field when creating new content in the Inquiry Management module, directs how the document should be handled when it is associated with an Interaction (Case) and Request (MED_Request__c) record.

For example, a document containing a standard response to a question may have a Delivery Option value of Merge Into Package, which indicates that the document will be inserted into the fulfillment package when the fulfillment package generation process completes. Meanwhile, a document containing a journal article may have a Delivery Option value of Attach Separate, Original Format, which indicates that the document will be added as an unmodified article to the Fulfillment record as a file during the fulfillment package generation process and will be included as an attachment when a requester is emailed the fulfillment response.

The table below lists all of the possible document behaviors.

Document delivery options​
Delivery optionDescription
Attach Separate, Original FormatThe document will be included in the fulfillment package as a separate file or attachment in the format that it was originally uploaded in.
Attach Separate, PDFThe document will be included in the fulfillment package as a separate PDF file.
Merge into PackageThe document will be combined with other documents related to the Interaction record that also have the Merge into Package delivery option, and all of the documents will be included in the fulfillment package as a single PDF file.
Send as LinkThe document will be delivered to the requester as a link.
HTML OnlyThe document will be included in an email body message. This should only be used if the fulfillment package is to be sent via the email method, and only the information on the Content (rich text) (mvn__CM_Content_Rich_Text__c) field on the Document Version record will be used.
Troubleshoot Nintex errors​

If you experience an error during the fulfillment package generation process, Medical Information Cloud recommends performing the following troubleshooting steps:

  • Make sure the documents actually have files and placeholders.

  • Review the Special considerations section below and check every document in the package for compliance.

If you still experience any issues, please open a Nintex case with the error ID.

Special considerations​

Please keep the following special considerations in mind when creating and preparing any documents to be included in fulfillment packages and when running the fulfillment package generation process:

  • Users must be assigned the Medical Information Cloud User (MED_Medical_Information_Cloud_User) permission set group, which includes the DocGen User (DDP_User_All) permission set.

  • The file types that can be converted to PDFs for generating fulfillment packages include:

    • Microsoft Word (.doc, .docx)

    • Microsoft Excel (.xla, .xlsx, .xlsm)

    • Microsoft PowerPoint (.ppt, .pptx)

    • PDF

    • Plain Text (.txt)

    • CSV (comma-separated values)

Note: Any non-Microsoft documents will be attached separately, producing multiple files instead of one consolidated PDF.

Warning: Do not mix .doc and .docx files within the same package.

  • Only native Word fonts are supported. If a generated PDF has font issues, embed the fonts in the Microsoft document(s) and regenerate the package.

  • The following DDP features are supported:

    • Insert-update

    • Data sources

    • Merge fields

  • The following DDP features are not supported:

    • Pause to edit

    • DocGen package forms

    • Documents (list on DDP is dynamically created and any in the DDP template are ignored)

  • Do not password protect files.

  • Do not upload a file and use the Context (rich text) (mvn__CM_Content_Rich_Text__c) field on a document. This is because the Generate Package button for generating the fulfillment packages merges documents without rich text while the Digital Fulfillment button for creating the email body message for the Digital Fulfillment feature only merges documents with rich text.

  • If you are using the Digital Fulfillment feature, merge fields that reference a nonexistent field and/or return a null or empty value will simply appear blank in the email and will not throw an error. However, merge fields that include HTML code (e.g., \<span\> elements) will throw an error.

  • If you are using Email-to-Case, make sure you include at least one cover letter component that references the Case Thread Token (MED_Case_Thread_Token__c) field on the Fulfillment record.

Send fulfillment packages via email​

After a fulfillment package is generated, users can send the fulfillment package to the requester via channels like email, mail, chat, fax, and in-person delivery. For email deliveries, users can use either the Email Fulfillment (MED_Email_Fulfillment) button or the Digital Fulfillment (MED_Generate_Fulfillment_Letter) button on the Fulfillment record page. The two buttons use different email components and processes to send the fulfillment package, and Medical Information Cloud recommends using the latter for emailing as it is a newer feature in Medical Information Cloud that is more flexible for digital deliveries. You will need to add the Digital Fulfillment quick action to the appropriate page layout to enable it for users.

Email Fulfillment​

If a user clicks the Email Fulfillment button on the Fulfillment record page, an email component will open in a new subtab and attach the fulfillment package to the email. The email body can be configured with an email template. For more information, reference Salesforce's documentation on Email Templates in Lightning Experience.

Digital Fulfillment​

If a user clicks the Digital Fulfillment button on the Fulfillment record page, a Configure Fulfillment Package modal will open where the user can modify and confirm the content to be included in the email. Each piece of information is pulled from the Content (rich text) (mvn__CM_Content_Rich_Text__c) field on a Document Version record, and if a section contains multiple pieces of information, users can drag and drop the content to reorder how they appear in the email body. When the user then clicks Email at the bottom of the Configure Fulfillment Package modal, an email component will open in a new subtab. The email body will be populated according to the information from the Configure Fulfillment Package modal and the email attachments will include the generated fulfillment package. Users without the Customize Response on Fulfillment permission set can change the To and From values but cannot modify the Subject field, the Body message, or the attachments. For more information about the fields in the Digital Component email, reference the Digital Fulfillment email component fields table below.

Note: The Configure Fulfillment Package modals for the fulfillment package generation process and for the Digital Fulfillment feature are separate and different. The former is used to generate the cover letter components and merge related documents into the fulfillment package while the latter is used to generate the body message and attach files to the email. However, the format and content of the cover letter and the email body are both controlled by the Dynamic Fulfillment Setting custom metadata type and may be identical. As a result, for information on how to configure the Configure Fulfillment Package modal for Digital Fulfillment, reference the Configure cover letter component behavior section above.

Digital Fulfillment email component fields​
FieldDefault valueAdditional notes
FromDefaults to the Fulfillment Outbound Email (MED_Fulfillment_Outbound_Email__c) value on the selected country or segment's Local Setting (MED_Local_Setting__mdt) custom metadata record. The email on the Fulfillment Outbound Email field must be an organization-wide email address.The From field will default to the Fulfillment Outbound Email value but will include all available organization-wide email addresses as well as the current user's email address for the user to select from.
ToDefaults to the Email (MED_Email__c) value on the Fulfillment record.
CCDefaults to the CC Email (MED_CC_Email__c) value on the Fulfillment record.
BCCN/A.
SubjectDefaults to the Fulfillment Email Subject Label (MED_Fulfillment_Email_Subject_Label__c) value on the selected country or segment's Local Setting (MED_Local_Setting__mdt) custom metadata record. The value on the Fulfillment Email Subject Label field must be a reference to a custom label. For new installs of Medical Information Cloud on Fall '25 (or above), the Default (Default) Local Setting metadata record uses the MED_Fulfillment_Email_Subject custom label.The custom label can include merge fields.
BodyIncludes the Content (rich text) (mvn__CM_Content_Rich_Text__c) value on the Document Version (mvn__CM_Document_Version__c) record of every document to be included in the fulfillment package. In other words, this is the merged result of the content inside the Configure Fulfillment Package modal after initiating the Digital Fulfillment feature. Merge fields in the cover letter component's rich text are automatically replaced with the corresponding Fulfillment record values.The Body field can have a maximum of 384,000 characters, according to Salesforce's Email Body Character Limits. Users can add images to the Body field but should only embed publicly available images that are either hosted in a Salesforce org and shared with a link or hosted on an external website to the Body field; users should not use the image option in the rich text toolbar to attach local images. To best ensure that images are properly included in the fulfillment emails, users should either insert the URL of the image or copy the image from the public location (e.g., right click on the image and select Copy) and then paste the image into the rich text field (e.g., right click in the field and select Paste).
Related RecordShows the ID of the related Fulfillment record.
AttachmentsIncludes all of the files on the Fulfillment record.Users can click the X icon on an attachment to remove it from the email as well as drag and drop the attachments to reorder them.

Configure follow-up opt in/opt out emails​

Requesters can opt in or opt out of receiving email updates from Request Follow-Ups. To configure this feature, first create new public sites for both opting in and opting out and then update the out-of-the-box Fulfillment email templates to include these two options.

Create a public site​

To create an opt-in site:

  1. In the Quick Find box in Setup, search for and select Sites.

  2. Click New.

  3. Add a Site Label (this will be the name of the site as seen in the user interface).

  4. The Site Name field automatically populates with an API name based on the value in the Label field.

  5. Set the site's default web address, e.g., "subscribe".

  6. Set the Active Site Home Page to MED_RequestFollowUpSubscribe.

  7. Leave the remaining fields with their default values.

  8. Click Save.

To create an opt-out site:

  1. In the Quick Find box in Setup, search for and select Sites.

  2. Click New.

  3. Add a Site Label (this will be the name of the site as seen in the user interface).

  4. The Site Name field automatically populates with an API name based on the value in the Label field.

  5. Set the site's default web address, e.g., "unsubscribe".

  6. Set the Active Site Home Page to MED_RequestFollowUpUnsubscribe.

  7. Leave the remaining fields with their default values.

  8. Click Save.

Updating out-of-the-box fulfillment email templates​

To update the Fulfillment Template for opting in:

  1. In the Quick Find box in Setup, search for and select Classic Email Templates.

  2. Click Fulfillment Template.

  3. Click Edit HTML Version.

  4. In the Subscribe Public Site field replace with the URL of the opt-in site you created.

  5. Click Save.

To update the Follow-up Fulfillment Template for opting out:

  1. In the Quick Find box in Setup, search for and select Classic Email Templates.

  2. Click Follow-up Fulfillment Template.

  3. Click Edit HTML Version.

  4. In the Unsubscribe Public Site field, replace it with the URL of the opt-out site you created.

  5. Click Save.

Updating custom fulfillment email templates for opting in​

To update the custom Fulfillment template for opting in:

  1. In the Quick Find box in Setup, search for and select Classic Email Templates.

  2. Click or create the desired template.

  3. Click Edit HTML version.

  4. In the Email Body field, build your embeddable link by combining the Opt In Site link with the URL formula provided and replacing the Subscribe Public Site with the URL of the opt-in site you created.

    :::: ::: title Email Body Example :::

    Opt In Site link: https://micsit-medinfo.cs122.force.com/subscribe

    URL formula: (Subscribe Public Site)?token=

    Result: https://micsit-medinfo.cs122.force.com/subscribe?token= ::::

  5. Embed the result into the desired text (example: Click Here) within the Email Template.

  6. Click Save.

Updating the custom follow-up fulfillment template for opting out​

To update the custom follow-up fulfillment template for opting out:

  1. In the Quick Find box in Setup, search for and select Classic Email Templates.

  2. Click or create the desired template.

  3. Click Edit HTML Version.

  4. Build your embeddable link by combining the Opt Out Site link with the URL formula provided and replacing the Subscribe Public Site with the URL of the opt-out site you created.

    :::: ::: title Email Body Example :::

    Opt out site link: Build your embeddable link by combining the Opt Out Site link with the URL formula provided by replacing (Subscribe Public Site) with the URL of the opt-out site you created.

    URL Formula: (Unsubscribe Public Site)?token=

    Result: https://micsit-medinfo.cs122.force.com/unsubscribe?token= ::::

  5. Embed the result into the desired text (example: Click Here) within the Email Template.

  6. Click Save.

When a user clicks either the subscribe or unsubscribe link in one of the templates used above, the follow-up consent fields on the associated request automatically update in the following manner:

  • Opting In: Sets the Requester Consent checkbox to checked.

  • Opting Out: Sets the Requester Consent checkbox to unchecked and populates the opt-out date field.

Account​

An Account is a record that stores information about a person or business, including name, title, and historical interactions. Examples of Accounts include:

  • Health Care Professionals (HCPs), e.g., doctors and pharmacists

  • Non-HCPs, e.g., consumers and payers

  • Employees, e.g., sales representatives and medical science liaisons (MSLs)

  • Institutions, e.g., hospitals and pharmacies

An Account record can be configured using the following custom metadata types:

Account records are also dependent upon the Account object.

Account Contact Information synchronization​

Medical Information Cloud provides a utility to synchronize Account data with Contact Information records. For example, the Account Phone field might be used by non-agents as the work number for an HCP. To make that information available to the agents in the Inquiry Management module, the Account Contact Info Sync can be configured to create/update a related Contact Information record. The synchronization is a one-way sync. The Contact Info Records are configured to be locked.

Configuring Account fields to sync to Contact Information records​

For the Account Contact Information synchronization to work, the Enable Contact Info Mappings (MED_Enable_Contact_Info_Mappings__c) field must be enabled in the Global Setting (MED_Global_Setting__mdt) custom metadata type.

The fields that trigger the creation or update of an associated Contact Info record can be configured by creating an Account Field Contact Info Mapping record. Provide the following information:

  • Account Field API name of the field that should trigger the update.

  • Record Type Developer name of the Contact Info record that should be created/updated.

  • The field on the Contact Info Record to map the value to. This should be the same type as the source field.

  • Optionally provide the Type that should be set on the contact info record.

Once configured, any updates to the account trigger the synchronization of the account field to the proper contact info record.

Locking synced records​

The records which are created using the functionality have a source of 'Parent Account', so by default, they will be locked by the Locked Record Handler unless it has been reconfigured.

Note: Changing this formula to allow the records to be edited may result in data being out of sync and/or being overwritten when the account information changes.

Initializing Data​

If the product is being installed in a Salesforce instance that already has account data, then the synchronization must be initialized through a batch job. To kick off the batch job, perform these steps:

  1. Open an Execute Anonymous Window. See Salesforce's documentation.

  2. Enter the following code: MED_AccountContactInfoSync batchJob = new MED_AccountContactInfoSync();``Database.executeBatch(batchJob);

  3. Click Execute.

A status of "Success" should be displayed in the log panel.

You should also see jobs being executed under Setup > Jobs> Apex Jobs. You can abort the job from this screen if necessary.

Data change requests​

Data change requests (DCRs) represent a requested change to a managed Account or Contact Information record within . While typically used in conjunction with a Master Data Management solution, Medical Information Cloud supports the generation of DCR records absent of a third-party Master Data Management solution.

You can use either Medical Information Cloud's native DCR handler or a custom DCR handler to process requested changes. Both native and custom DCR handlers can be called in the following scenarios:

  • The Account record is created via the New Account modal, which users can access when searching for Accounts.

  • The Account record is updated.

  • The Contact Information record is created.

  • The Contact Information record is updated.

Native DCR process​

Note: This section only applies to Medical Information Cloud's native DCR functionality, not custom DCR handlers. Your instance uses Medical Information Cloud's native functionality if the value of MED_Global_Setting__mdt.MED_DCR_Create_Handler_Class__c is MED_DCRCreateHdlr.

The Data Change Request object stores information about requested changes to managed Account and Contact Information records and is on the master side of a master-detail relationship with the Data Change Request Line object, which captures the old and new values for change requests.

Every time a data change is submitted and invokes the native DCR handler, the DCR handler creates a Data Change Request record that has a record type of Account and that looks up to the relevant Account record. The DCR handler also creates any additional Data Change Request records and Data Change Request Line records that are needed to process the requested change or group of changes that were submitted together. See Native DCR data model.

A single Data Change Request record cannot capture more than one change request. This means that each Data Change Request record should only ever have one of these lookup fields populated at a time: MED_Account__c, MED_Contact_Information__c, or MED_Parent_Account__c. When multiple Data Change Request records are created in a single step, the Account Data Change Request record is always the parent, and the other Data Change Request records that were created in the same step are linked to the parent record via the MED_Parent_Data_Change_Request__c field.

Data Change Request records that have a Status of Pending are sent to Veeva Network, the Master Data Management source for a data steward to process. Once sent, the Status is set to Submitted, and after a data steward processes the change request, the Status is changed to Processed, the appropriate Data Change Request and Data Change Request fields are updated, and any necessary merge work occurs.

Account merge work prevents duplicate Account records from being created. When the Data Change Request's Type field is set to New and the Status field is set to Processed, Medical Information Cloud verifies that an Account with an External ID matches the value of MED_Data_Change_Request__c.MED_Account_External_ID__c does not already exist in the product. If an existing Account record has an External ID that matches, the existing record and new record are merged using Salesforce's native merge feature. Metadata from the existing record is kept if the existing and new records have conflicting data.

Medical Information Cloud also verifies that a new Contact Information record is not a duplicate by looking at the External ID field on existing Contact Information records to see if the value matches the value of MED_Data_Change_Request__c.MED_Address_External_ID__c . If an existing Contact Information record has an External ID that matches, repoints MED_Data_Change_Request__c.MED_Contact_Information__c from the new Contact Information record to the existing Contact Information record and then deletes the new Contact Information record.

Upon completion of any necessary merge work or if no merge work is required, a trigger updates the External ID field on the related Account or Contact Information record.

Enable native and custom DCRs​

To enable DCR generation:

  1. Navigate to the appropriate Global Setting custom metadata record, and click Edit.

  2. Set the DCR Globally Active field to true.

  3. Enter a value into the DCR Create Handler Class field.

    • To use native DCR functionality, enter MED_DCRCreateHdlr.

    • To override default functionality and use a custom DCR handler, enter the Apex class name that implements MED_DCRCreateIntf. When a change event occurs, this handler class is sent the full record and, if applicable, the old record and contact information to create DCR records as you would like.

  4. Click Save.

Configure native DCR functionality​

Note: This section only applies to Medical Information Cloud's native DCR functionality. Your instance uses Medical Information Cloud's native functionality if the value of MED_Global_Setting__mdt.MED_DCR_Create_Handler_Class__c is MED_DCRCreateHdlr.

After DCRs are enabled, you can configure native DCR functionality to specify when to generate DCRs and which users should not trigger DCRs. You can also integrate Veeva Network with your Medical Information Cloud instance and use it as your Master Data Management source.

Configure DCR change events​

To configure the DCR creation behavior, leverage the Account Field Setting custom metadata type to ensure the correct fields are monitored for the appropriate change events and included within the corresponding DCR records. To include a field within the DCR scope, populate the Include in DCR field with the appropriate change event for a given object (e.g. Account and Contact Information), field, country, and record type (e.g. HCP).

Opt-out users​

You can configure the DCR feature to exclude updates from specific individuals. This can be helpful in cases where you want to bypass the DCR generation for a particular user, such as an integration user, data steward, or administrator. To exclude a user from DCR consideration:

  1. Locate the MIC Feature Flag custom setting within the Salesforce administrative user interface.

  2. Create a MIC Feature Flag custom setting record for each profile and/or user that should be excluded from the DCR process. Be sure to check the Bypass DCR field when creating the records.

Configuration considerations​

Important points to consider when leveraging DCRs are as follows:

  • Only new Accounts (inserts) that are created via the New Account modal, which users can access when searching for Accounts, are considered for a DCR.

  • Only updated Accounts that are sourced from an Account Master are considered for a DCR. If an account has a value present within the MED_External_Id__c field, it is deemed to have been sourced from an Account Master.

  • DCRs are generated based on the underlying configuration which may include fields from both Accounts as well as related Contact Information.

  • DCR configuration supports separate configurations for Inserts and Updates.

  • When merging Accounts, there may be a delay from the time the DCR status is processed to when the Account is fully merged because the DCR status update and Account merge processes are asynchronous.

  • When merging Accounts, triggers, and workflows will not fire on child objects that are re-parented to the new Account.

Native DCR data model​

Note: This section only applies to Medical Information Cloud's native DCR functionality. Your instance uses Medical Information Cloud's native functionality if the value of MED_Global_Setting__mdt.MED_DCR_Create_Handler_Class__c is MED_DCRCreateHdlr.

The DCR entity relationship diagram depicts the change request data model and field requirements for native DCR functionality. Data Change Request and Data Change Request Line fields listed on the entity relationship diagram are required.

The native DCR data model relies on Data Change Request record types. Data Change Request object record types include:

  • Account - utilized when the associated Account record is either (1) new or modified or (2) the parent Account of other modified records.

    A Data Change Request record with the Account record type must exist for every change request. This record is at the top of the DCR data model and must look up to the Account record that is new or modified or that is related to the Institution or Contact Information record that is new or modified. Depending on the change request, the Data Change Request record may not have any Data Change Request Line records associated.

  • Address - utilized when the associated Contact Information record is new or has been modified.

    The Data Change Request record for the Address record type must look up to the Contact Information record that is new or modified, must look up to the Data Change Request record for the Account record type, and must have at least one Data Change Request Line record associated.

  • Parent - utilized when the associated Institution Account record is new or has been modified.

    The Data Change Request record for the Parent record type must look up to the relevant Account record for the Institution that was created or modified, must look up to the Data Change Request record for the Account record type, and must have at least one Data Change Request Line record associated.

DCR objects​

The Data Change Request object stores information about requested changes to managed Account and Contact Information records and is on the master side of a master-detail relationship with the Data Change Request Line object, which captures the old and new values for change requests.