Skip to main content

Spring '26 (v18) Release Notes

This topic contains the V18 release notes for Medical Information Cloud. V18 is the Spring '26 release. The release notes are organized into these high-level sections:

As this page is maintained and updated over time to ensure accurate and timely information, Mavens recommends referencing the release notes online rather than printing and using static versions of the page.

note

The release notes on this page cover the Spring '26 work items that have been documented to date. Additional features, fixes, and metadata changes that ship in Spring '26 will be appended to this page as their documentation lands.

Installation and upgrades

The Medical Information Cloud Spring '26 release can be installed with the Install Service at http://install.komodohealth.com/products/mic/latest. New installs of Medical Information Cloud will be on the latest release while current customers will need to run and deploy the latest update.

warning

Remember to complete the steps in the Recommended post-upgrade actions section below as appropriate.

New features

The V18 release of Medical Information Cloud contains several new features whose functionalities are detailed below. Details about enablement and configuration are included within the product documentation.

Region lookup on Interaction (Case)

Medical Information Cloud now keeps each Interaction (Case) record linked to a Region (Region__c) record that matches the Country selected on the interaction.

Interaction

The Region (MED_Region__c) lookup field on the Interaction (Case) object points to the Region (Region__c) record whose Country ISO Code (Country_ISO_Code__c) matches the value of the Country (MED_Country__c) picklist on the interaction. The Set Case Region trigger action keeps the lookup in sync: when the Country field is set or changed, the trigger action stamps the matching Region record's ID on the lookup, or clears the lookup if no Region record matches.

The field is visible on the Case - Lightning Admin layout and is hidden from the standard Case - Lightning layout. Read access is granted by the Medical Information Cloud Admin (MED_Medical_Information_Cloud_Admin) and Medical Information Cloud User (MED_Medical_Information_Cloud_User) permission sets.

For product documentation, including more information on how to use and configure the feature, refer the Region lookup on Interaction section.

Related work item(s): MIC-4001

Digital Fulfillment and cover letter enhancements

Medical Information Cloud now ships an updated Fulfillment flow that separates cover letter assembly from final document delivery. Fulfillment specialists can prepare and review the cover letter and the case documents independently, then merge the resulting PDFs into a single finalized package before sending. The new flow uses the Lightning email composer for digital delivery and replaces the legacy Configure Fulfillment Package modal title with Enhanced Email Composer to better reflect what users see on the screen.

New Fulfillment Flow

To support the new flow, the Fulfillment (MED_Fulfillment__c) object has two new rich text fields:

  • Questions (MED_Questions__c) - It holds the list of questions answered by the fulfillment. The field is populated automatically when the Digital Fulfillment (MED_Generate_Fulfillment_Letter) quick action is used and is also refreshed by the Refresh Request List (MED_Refresh_Request_Fulfillments) quick action.

  • Attachments (MED_Attachments__c) - It holds the list of files to be sent as attachments with an email fulfillment. The field is refreshed automatically whenever files are attached to or removed from the Fulfillment (MED_Fulfillment__c) record.

The new Fulfillment flow is exposed on Fulfillment records through two new quick actions:

  • Prepare Fulfillment (MED_Merge_Cover_Letter) - It opens a modal where the user selects cover letter components and case documents, reorders them, and chooses delivery options for each section. When the user clicks Merge, Medical Information Cloud generates one PDF for the cover letter components and a second PDF for the case documents.

  • Finalize Fulfillment (MED_Finalize_Merge_Letter) - It opens a modal that lists the files generated by Prepare Fulfillment in the desired final order. When the user clicks Merge, Medical Information Cloud combines the selected files into a single final fulfillment package PDF and deletes the intermediate documents.

The split between Prepare Fulfillment and Finalize Fulfillment preserves the formatting of each source document. Cover letter components and standard response documents are converted to PDF before being combined, which prevents the cover letter formatting (margins, fonts, headings) from being applied to the standard response document during the final merge.

note

To use this functionality, an administrator must add the new Prepare Fulfillment (MED_Merge_Cover_Letter) and Finalize Fulfillment (MED_Finalize_Merge_Letter) quick actions to the Fulfillment (MED_Fulfillment__c) page layout(s) in the org. The actions are not deployed to any specific page layout on upgrade.

Additionally, the legacy Generate Package (MED_Generate_Fulfillment_Package) and Email Fulfillment (MED_Email_Fulfillment) actions remain available on the Fulfillment (MED_Fulfillment__c) record so that customers who have not yet adopted the new flow can continue to use the existing process.

warning

The new flow assumes that the Global Case Documents Template and Global Final Template DDP records exist and that the Local Settings (MED_Local_Setting__mdt) record for each country references those DDPs in the Template Case DDP Name (MED_Template_Case_DDP_Name__c) and Template Final DDP Name (MED_Template_Final_DDP_Name__c) fields. Without those entries, Prepare Fulfillment and Finalize Fulfillment will not produce the expected output.

For product documentation, including more information on how to use and configure Digital Fulfillment, reference the Digital Fulfillment section.

Related work item(s): MIC-4066, MIC-4191, MIC-4319

Presubmit Validation for Adverse Events

Administrators can now enforce client-specific completeness checks on an Adverse Event (MED_Adverse_Event__c) record and its child records before the Adverse Event is submitted to safety, either through the Send To Safety (MED_Send_To_Safety) quick action or through the Generate E2B (MED_Generate_E2B_Action) quick action (if added in the Page Layout).

A new Run Presubmit Validation (MED_Run_Presubmit_Validation__c) checkbox field is available on the Adverse Event (MED_Adverse_Event__c) object and its child objects.

For product documentation, including detailed information on how to configure and use this new feature, reference Presubmit Validation for Adverse Events.

Related work item(s): MIC-4136, MIC-4238

Account Search optimization for omnichannel workflows

The MIC - Case Accounts Quick Search (mvn.medCaseAccountsQuickSearch) component, also known as the Quick Search component or Account Search, is no longer scoped to the Interaction (Case) object alone. Administrators can now add this component to any object's Lightning Record Page or Experience Cloud Object Page as long as that object has a relationship to the Interaction (Case) object. This unblocks Account Search on omnichannel surfaces such as the Messaging Session record page, where representatives must locate or create an account before opening an interaction.

To support generic placement, the component exposes a new Case Lookup Field API Name property and a new Apex method (MED_AccountSearchCtrl.getObjectApiNameByRecordId) that resolves the host object's API name at runtime. If the Case Lookup Field API Name property is left blank, the component falls back to the standard mvn__MED_Case__c lookup field to preserve the previous behavior for customers whose custom objects already use that lookup convention.

For product documentation, including step-by-step configuration in the Lightning App Builder, reference the Quick Search component section.

Related work item(s): MIC-3144, MIC-3971

Content Search Configuration

Medical Information Cloud now lets administrators configure, on a per-request basis, whether a Regulated Content Cloud published-document search runs against standard Einstein search or Data 360. A new custom metadata type, Content Search Settings (mvn__CM_Content_Search_Settings__mdt), defines records that match on attributes of the inbound search — such as country, channel, or whether the call came through the published-document service — and stamp the matched record's algorithm, search type, search index, data space, and minimum score onto the request before it runs.

Data 360 is a net-new content search backend introduced in V18. Administrators can, for example, route US published-document searches to Data 360 while leaving other countries on Einstein, or restrict Data 360 to phone-channel searches only. If no Content Search Settings record matches an inbound request, the search runs on standard Einstein search, so V18 behaves the same as previous releases until an administrator authors at least one record.

For product documentation, including configuration steps and criteria examples, see Content Search Configuration.

Related work item(s): MIC-4568

Updated features

Initial focus on the Notepad component when opening an Interaction

To reduce the number of clicks needed before a user can start typing notes during a call or while triaging an Interaction (Case), the Notepad (medNotepad) Lightning component now places the cursor in its rich text editor automatically when the Interaction record page loads.

Notepad

Earlier, the page opened with focus on the Name (First Name/ Last Name) field of the Account Search widget, which required users to manually click into the Notepad before they could begin typing.

This change applies to both new and existing Interaction records and runs once per page load. If the Notepad component is not on the Interaction's Lightning record page, the application falls back to the standard Salesforce default focus behavior for that page (typically the first editable field in the Highlights Panel or Layout). This update is shipped "on" by default for all customers and no additional configuration is required.

Reference the Notepad section for more details.

Related work item(s): MIC-1382

Unique filenames for generated E2B (ICSR) files

Generated E2B (ICSR) XML files now include the Adverse Event Name in their filename so that each generated file is uniquely identifiable.

note

ICSR Batch Number (MED_ICSR_Batch_Number__c) is the field where the identifier is stored.

The new filename pattern is ICSR_<yyyyMMddHHmmss>_<Adverse Event Name>.xml.

Reference the E2B(R3) generation section for more details. section for more details.

Related work item(s): MIC-4277

MIC Essentials package tweaks from training prep

Several small adjustments were applied to the P-App-MIC-Setup and P-App-MIC packages so the MIC Essentials experience matches what the training team validated. These include adding the Close Interaction button to the Interaction FlexiPage, surfacing My PQCs Pending Reconciliation and My AEs Pending Reconciliation list views on the Home page, adjusting the corresponding reconciliation reports so they group by reconciliation group, adding the Dashboards and Reports tabs to the manager, viewer, and personal-report permission sets, adding the MED_Inquiry_Agent_Group public group, defaulting the Enhanced Viewer extensions setting to pdf, doc, docx, and correcting the spelling of the MED_Custom_Response permission set label.

Related work item(s): MIC-4348

Highlights panel for closed Adverse Event records

The Adverse Event Lightning page layout now keeps a highlights panel visible when an AE record is closed. The closed-state highlights panel exposes a streamlined action bar (with Reopen AE and, when E2B is enabled, Send to Safety) so users can reopen a closed AE or send it to safety without having to leave or re-open the record.

Related work item(s): MIC-4329

FFLIB upgrade regression coverage for fnds-core-unlocked

The fnds-core-unlocked foundation package was upgraded to a newer FFLIB release that introduces split Domain interfaces, Application-factory changes, and user-mode support in the Unit of Work. Regression coverage was executed against the MIC dependent applications (MCM and Pubs) to confirm that package installs, unit-of-work transactions, selector queries, domain/trigger logic, user-mode permission checks, and workflow task attachments all continue to behave as expected with the new FFLIB version.

Related work item(s): MIC-4270

Field Audit tracking for ContentVersion and ContentDocument

MIC's Trigger Action Framework and Field Audit Settings were extended to cover the standard Salesforce ContentVersion and ContentDocument objects (specifically the Title and Description fields on each). Administrators can now configure Field Audit Settings to track changes to those fields the same way they configure auditing for other tracked objects in MIC.

Related work item(s): MIC-4242

Default Value Mapping product matching for MIR integration

The default product-matching behavior for the Medical Information Request (MIR) integration was updated to always use the Value Mapping, Name strategy. The configurable Product Match Strategy field on the Global Settings custom metadata and on the product setup screens was removed; MIC now relies on the available MIC Value Mappings to match inbound MIR products and falls back to matching the product record's Name when no Value Mapping is configured. Customers control the matching behavior by maintaining (or omitting) the appropriate Value Mapping records.

Related work item(s): MIC-4222

E2B updates

Several updates have been made to the E2B(R3) reporting functionality in the Spring '26 release. These updates are delivered through the optional mic-e2b package (available in the Install Service as the Medical Information Cloud - E2B configuration) and through the default Adverse Event picklist values that ship with the Medical Information Cloud - Setup configuration. Customers that use E2B reporting can install these updates either alongside the typical upgrade by checking the Install Package mic-e2b step in the Medical Information Cloud - Setup configuration or any time after the Spring '26 release using the Medical Information Cloud - E2B configuration.

Set the MedDRA version globally for E2B files

Previously, the MedDRA version that the E2B(R3) specification requires for every MedDRA-coded element (for example, MedDRA Version for Medical History at D.7.1.r.1a or MedDRA Version for Indication at G.k.7.r.2a) had to be entered as a per-record value on each Adverse Event child record. Administrators and users had to keep the value identical across every record, even though the E2B specification states that a single submission must use one MedDRA version end-to-end.

In Spring '26, administrators set the MedDRA version once on the new MedDRA Version (MED_MedDRA_Version__c) field on the MED_E2B_Setting__mdt custom metadata type. The E2B generator then uses that value for every MedDRA-coded element in the generated XML. If a record-level MedDRA version value is still populated on a child record, the generator continues to honor the record-level value for that element, which preserves backward compatibility for organizations that have not yet migrated.

The previously used record-level MedDRA version fields are deprecated in this release (see Deprecated and deleted items). Their labels have been prefixed with (DEPRECATED) so that administrators can identify and remove them from page layouts during their upgrade.

The new MedDRA Version field accepts up to four characters and follows the E2B(R3) Data Type 4AN rule, allowing numeric values and the . (dot) separator (for example, 26.0).

For configuration steps, see Set the global MedDRA version on the E2B Setting custom metadata record below. For the broader E2B(R3) feature reference, see the E2B(R3) generation section on the Primary objects page.

Related work item(s): MIC-3909

Sender telecom elements and tel:, fax:, mailto: prefixes

Previously, generated E2B(R3) files did not include the sender's telephone (C.3.4.6), fax (C.3.4.7), or email address (C.3.4.8) elements at all, and the reporter's telephone (C.2.r.2.7) was written without the required tel: URI prefix. As a result, downstream safety systems that validate against the E2B(R3) schema flagged the generated files for missing or malformed contact elements.

In Spring '26:

  • The sender's telephone, fax, and email values configured on the MED_E2B_Setting__mdt custom metadata type are now written into the generated E2B XML as \<telecom\> elements on the sender block (C.3.4.6, C.3.4.7, and C.3.4.8 respectively). Each element is written only when the corresponding setting value is populated; a blank setting value continues to omit the element from the file.

  • All \<telecom\> elements written for reporter and sender contact details are prefixed with the URI scheme that the E2B(R3) specification requires:

    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:

    If a value already begins with the correct prefix (for example, a sender email already stored as mailto:contact@example.com), the generator does not prepend the prefix a second time. If a value is populated using the nullFlavor_\<value\> syntax, the generated \<telecom\> element carries the prefix with no inline contact value and the corresponding nullFlavor attribute on the element (for example, \<telecom value="tel:" nullFlavor="MSK"/\>).

To support the new sender fax element, a new Sender Fax (MED_Sender_Fax__c) field is added to the MED_E2B_Setting__mdt custom metadata type and the E2B Setting Layout page layout.

For configuration steps, see Set the sender telecom values on the E2B Setting custom metadata record below. For the existing \<telecom\> tag reference (already documented for the Fall '25 / V17 release), see the Telecom tags subsection on the Primary objects page.

Related work item(s): MIC-3861

Adverse Event picklist values aligned with ICH E2B(R3)

Previously, the Dosage Units (MED_AE_Dosage_Units) and Time Units (MED_AE_Time_Units) global value sets that drive the dosage and duration picklists on Adverse Event child records used legacy labels that predate the ICH E2B(R3) reporting specification. For example, the dosage unit mg appeared as Mg, the dosage unit g appeared as G, and several units used the µ (micro) symbol rather than the UCUM-compatible u form expected by E2B(R3) consumers.

In Spring '26, both value sets are updated to use the UCUM / E2B(R3)-compliant values out of the box. The new values are summarized below.

Dosage Units value updates
Previous valueNew value
Gg
Mgmg
µgug
µg/kgug/kg
µg/m2ug/m2
lL
µlul
KbqkBq
MCimCi
µCiuCi
NCinCi
Molmol
Mmolmmol
µmolumol
Iu[iU]
Kiuk[iU]
MiuM[iU]
iu/kg[iU]/kg
Meqmeq
DF{DF}

The release also adds three new values to Dosage Units: mg/mL, [drp] (drops), and {DF} (dosage form).

Time Units value addition

A new 10.a value (label Decades) is added to the Time Units global value set, aligning with the ICH E2B(R3) UCUM annotation for decades.

The legacy values continue to appear in the global value sets but are flagged as inactive so that they no longer appear as available selections on new records. Existing records that already reference a legacy value retain that reference until the record is edited; this preserves the existing data while preventing new use of the legacy labels. Administrators that need to migrate stored picklist data on existing records should reference Recommended post-upgrade actions below.

The Adverse Event Drug (MED_AE_Drug) and Adverse Event Drug Closed (MED_AE_Drug_Closed) record types on MED_AE_Drug_Information__c are updated to expose the new values on their Dosage Units picklist.

Related work item(s): MIC-3752

Defect fixes and maintenance

The following table details defects and maintenance items that have been fixed in the Spring '26 release.

Fixed items
Work itemDescriptionNew behavior
MIC-3861Generated E2B(R3) files omitted the sender's telephone, fax, and email elements (C.3.4.6, C.3.4.7, C.3.4.8) entirely, and the reporter's telephone (C.2.r.2.7) was written without the required tel: URI prefix. Downstream safety systems flagged the generated files for missing or malformed contact elements.Sender telephone, fax, and email values are written to the generated XML when configured on the MED_E2B_Setting__mdt custom metadata type. Every \<telecom\> element is prefixed with the appropriate URI scheme (tel:, fax:, or mailto:). Values that already include the prefix or that are populated using the nullFlavor_\<value\> syntax are handled correctly.
MIC-3752The default Dosage Units and Time Units picklist values on Adverse Event records did not match the ICH E2B(R3) / UCUM conventions used by downstream safety systems, causing rejected or non-conformant submissions for the affected fields.The default Dosage Units and Time Units values ship with E2B(R3)-aligned labels. Legacy labels are retained as inactive picklist values so that existing records continue to render.
MIC-4333After a PQC record's Status was set to Submitted, the Enhanced Record Edit component continued to show all fields as editable until the user manually refreshed the browser.The Enhanced Record Edit component now re-evaluates the layout when the underlying record's state changes (for example, when the record type or layout changes after save) so the correct read-only layout is applied immediately after submission.
MIC-4332Salesforce switched off the legacy platformShowToast event, which left toast notifications broken in the P-App-MIC and P-App-MIC-mvn-mic-core repositories.All affected components were updated to use the supported lightning/toast module syntax so that user-facing toast notifications appear correctly across MIC.
MIC-4330Cloning a closed Request produced a new record with Status = Open but the wrong Record Type of MED_Request_Closed, leaving users unable to edit the cloned Request without first reopening it.The Request: Status Change flow now runs on insert as well as on status change, so cloned Requests are correctly created with Status = Open and the MED_Request record type, ready for editing.
MIC-4327Superfluous setup requirements that no longer apply to MIC remained in the MIC IQ - Org Setup configuration: the Enable Streaming API step, PushTopic and StreamingChannel object permissions on the default system administrator profile, and Email Tracking guidance on the help site.The Enable Streaming API step is removed from MIC IQ - Org Setup, PushTopic and StreamingChannel object permissions are no longer deployed with the default admin profile, and irrelevant Email Tracking guidance is removed from the help site.
MIC-4283Manually removing or changing the Account on a Case did not persist when the previous Account was a Person Account, because MIC's Case Trigger Framework was re-associating the existing Contact automatically.The Case Trigger Framework now watches for changes to AccountId and, when the Account is cleared or changed on a Case linked to a Person Account, explicitly clears the ContactId so the user's change persists after save.
MIC-4251Two MCM defects affected MIC Essentials users: the CM_Workflow_Task_Detail_Page FlexiPage was not activated as the org default, hiding the Complete Task button; and the CM_ContentReadOnly permission set did not include the CM_DocumentVersionPackageFileController Apex class, causing an Apex access error when previewing files.The CM_Workflow_Task_Detail_Page FlexiPage is now activated as the org default so the Complete Task button and full field set appear on workflow tasks. The CM_ContentReadOnly permission set now includes the CM_DocumentVersionPackageFileController Apex class so users with Content - Medical User or Content Read Only permission sets can preview attached files without error.

Metadata changes

The following subsections capture the changes against entities in key areas of Medical Information Cloud that are introduced in this release. This list is scoped to the work items documented above and is not exhaustive of the full Spring '26 release.

Custom labels

Custom label changes are listed in the table below.

New custom labels
Work item(s)Custom label(s)
MIC-4319MED_Digital_Fulfillment_Email_Composer
MIC-4066MED_Prepare_Fulfillment
MED_Finalize_Fulfillment
MED_Cover_Letter_Files
MED_Case_Documents
MED_Files_Merged
MED_Merge_Button

Objects

Object changes are listed below.

New object fields
Work item(s)ObjectField(s)
MIC-4001CaseMED_Region__c (Lookup to Region__c)
MIC-4191MED_Fulfillment__cMED_Questions__c (Rich Text)
MED_Attachments__c (Rich Text)
MIC-4238MED_Adverse_Event__c
MED_AE_Drug_History__c
MED_AE_Drug_Information__c
MED_AE_Medical_History__c
MED_AE_Primary_Source__c
MED_AE_Reaction__c
MED_AE_Results__c
MED_Run_Presubmit_Validation__c

Custom metadata types

Custom metadata type changes are listed in the table(s) below:

New custom metadata types
Work item(s)Custom metadata typeMetadata record name(s)
MIC-4191mvn__MED_Fulfillment_Child_Summary__mdtFulfillment Child Summary
New custom metadata type fields
Work item(s)Custom metadata typeField(s)
MIC-3909MED_E2B_Setting__mdtMED_MedDRA_Version__c
MIC-3861MED_E2B_Setting__mdtMED_Sender_Fax__c
MIC-4066mvn__MED_Local_Setting__mdtMED_Template_Case_DDP_Name__c MED_Template_Final_DDP_Name__c

Custom metadata records

Custom metadata record changes are listed in the table(s) below:

note

New custom metadata records are only available via the Medical Information Cloud - Setup plan in the Install Service.

New custom metadata records
Work item(s)Custom metadata type(s)Metadata record name(s)
MIC-4001mvn__TAF_Trigger_Action__mdtSet_Case_Region
MIC-4191mvn__MED_Fulfillment_Child_Summary__mdtQuestions
MIC-4191mvn__MED_Fulfillment_Child_Summary__mdtRequest_Documents
MIC-4191mvn__TAF_Trigger_Action__mdtFulfillment_Content_Doc_Link
MIC-4191mvn__TAF_Trigger_Action__mdtFulfillment_Content_Document

The Account Search optimization work items (MIC-3144 and MIC-3971) do not add or modify custom metadata records. Existing Account Search configuration metadata types, including mvn__MED_Global_Setting__mdt, mvn__Interface_Handler__mdt, and MED_LY_Layout__mdt, are unchanged in this release.

Modified custom metadata records
Work item(s)Custom metadata typeMetadata record names(s)
MIC-4066mvn__MED_Local_Setting__mdtDefault

Page layouts

Page layout changes are listed in the table(s) below:

Modified page layouts
Work item(s)ObjectPage layoutModification description
MIC-3909MED_E2B_Setting__mdtE2B Setting LayoutAdded the MedDRA Version (MED_MedDRA_Version__c) field to the layout.
MIC-3861MED_E2B_Setting__mdtE2B Setting LayoutAdded the Sender Fax (MED_Sender_Fax__c) field to the layout.
MIC-4001CaseCase-Lightning AdminThe Region (MED_Region__c) field is added to the layout.
MIC-4191MED_Fulfillment__cLightning Admin Feed Layout,
Lightning Closed Feed Layout,
Lightning Feed Layout
A Fulfillment Information section is added that contains the Questions (MED_Questions__c) and Attachments (MED_Attachments__c) fields.
MIC-4066MED_Fulfillment__cLightning Admin Feed LayoutThe Prepare Fulfillment (MED_Merge_Cover_Letter) and Finalize Fulfillment (MED_Finalize_Merge_Letter) quick actions are added to the Mobile and Lightning action section.
MIC-4066mvn__MED_Local_Setting__mdtLocal Setting LayoutThe Template Case DDP Name (MED_Template_Case_DDP_Name__c) and Template Final DDP Name (MED_Template_Final_DDP_Name__c) fields are added to the layout.
MIC-4191mvn__MED_Fulfillment_Child_Summary__mdtFulfillment Child Summary LayoutThe Child Relationship Name (MED_Child_Relationship_Name__c) and Child Query Where Clause (MED_Child_Query_Where_Clause__c) fields are reordered, and the System Information section no longer shows a detail heading.

Global value sets

Global value set changes are listed in the table(s) below:

Modified global value sets
Work item(s)Global value setModification description
MIC-3752MED_AE_Dosage_UnitsRenamed legacy values (for example, Mg -> mg, µg -> ug, Iu -> [iU]) to the ICH E2B(R3) / UCUM forms. Deactivated the legacy values so that they no longer appear as new selections. Added mg/mL, [drp], and {DF} as new active values.
MIC-3752MED_AE_Time_UnitsAdded 10.a (label Decades) as a new active value.

Validation rules

Validation rule changes are listed in the table(s) below:

note

New validation rules are only available via the Medical Information Cloud - Setup plan in the Install Service.

New validation rules
Work item(s)Custom metadata typeValidation ruleDescription
MIC-4568mvn__CM_Content_Search_Settings__mdtCM_Criteria_RequiredBlocks save when the Criteria field is blank.
MIC-4568mvn__CM_Content_Search_Settings__mdtCM_Data_360_Requires_Full_ConfigBlocks save when Search Algorithm is DATA_360 and any of Search Type, Search Index, Data Space, or Min Search Score is blank.

Apex classes

Apex class changes that are exposed to customer extensions and integrations are listed in the table(s) below:

New global Apex classes
Work item(s)ClassDescription
MIC-4568mvn.CM_DocumentSearchRequestRequest DTO that bundles every search input — keyword, filters, paging, region codes, and custom attributes — for the published-document and document-version search services. Adds an addCustomAttribute(key, value) helper.
MIC-4001MED_SetCaseRegion (mvn namespace)Trigger action handler that sets the Region (MED_Region__c) lookup on an Interaction (Case) based on the selected Country (MED_Country__c) value.
MIC-4191MED_FulfillmentSummaryOrchestrator (mvn namespace)Reads active MED_Fulfillment_Child_Summary__mdt records and dispatches each one to its configured formatter to build per-Fulfillment HTML and stamp it onto the configured target field.
MIC-4191MED_FulfillmentSummaryBridgeLets non-namespaced code call the namespaced orchestrator via the MED_IFulfillmentSummaryOrchestrator interface.
MIC-4191MED_IFulfillmentSummaryOrchestratorInterface used by MED_RequestFulfillmentsCreator to invoke the orchestrator and to stub the orchestrator in tests.
MIC-4191MED_FulfillmentChildListHtmlBuilder (mvn namespace)Formatter implementation that renders Fulfillment child records as an HTML bulleted list.
MIC-4191MED_FulfillmentChildTableHtmlBuilder (mvn namespace)Formatter implementation that renders Fulfillment child records as an HTML table using a field set for columns.
MIC-4191MED_FulfillmentFilesListHtmlBuilder (mvn namespace)Formatter implementation that renders the latest versions of files linked to each Fulfillment as an HTML bulleted list.
MIC-4191MED_FulfillmentReqDocsListHtmlBldr (mvn namespace)Formatter implementation that walks Fulfillment to Request Fulfillment to Request Document and renders the resulting document set as an HTML bulleted list.
MIC-4191MED_FulfillmentChildQuery (mvn namespace)Service used by the formatters above to query child records with field-set-driven select lists and an optional filter.
MIC-4191MED_FulfillmentListHtmlRenderer (mvn namespace)Renderer used by the formatters above to produce the inner <ul> markup.
MIC-4191MED_FulfillmentChildTableHtmlRenderer (mvn namespace)Renderer used by the table formatter to produce the inner <table> markup.
MIC-4191MED_FulfillmentChildHtmlContext (mvn namespace)Shared schema-resolution helper used by the formatters above.
Modified global Apex classes
Work item(s)ClassModification description
MIC-4568mvn.CM_PublishedDocumentServiceAdds a primary executeSearch(CM_DocumentSearchRequest req) method. The previous 7-argument and 8-argument overloads remain as back-compat shims that build a request and delegate.
MIC-4568mvn.CM_DocumentVersionSearchServiceAdds a primary executeSearch(CM_DocumentSearchRequest req) method. The 14-argument overload remains as a back-compat shim.
MIC-4066MED_FulfillmentPackageDataProvider (mvn namespace)New callable actions are exposed: getCaseTemplateDDPNameForCountry, getFinalTemplateDDPNameForCountry, getCoverLetterFilesList, getFulfillmentCaseDocsFilesList, getFinalFilesList, and setFinalDDPFiles. These power the new Prepare Fulfillment and Finalize Fulfillment modals.
MIC-4066MED_FulfillmentPackageService (mvn namespace)New methods support the case-documents and final-merge flows: getCoverLetterFilesWithoutCaseDocuments, getFulfillmentCaseDocsFiles, and getFinalFilesList.
MIC-4066MED_LocalSettings (mvn namespace)New templateCaseDdpName and templateFinalDdpName accessors expose the new Local Setting (MED_Local_Setting__mdt) fields.
MIC-4191MED_RequestFulfillmentsCreator (mvn namespace)After Request Fulfillment records are created or refreshed, the trigger handler now invokes MED_IFulfillmentSummaryOrchestrator.summarizeFulfillmentChildren on the affected Fulfillment records and persists the resulting HTML on the Fulfillment in the same transaction.
MIC-4238MED_AEChildObjectsUpdatePropagates the new MED_Run_Presubmit_Validation__c value from a parent Adverse Event to its child records when the value changes on the parent.
MIC-4277MED_E2BGeneratorAppends the Adverse Event Name to the generated E2B filename so that every generated ICSR file is uniquely named.
MIC-3144, MIC-3971MED_AccountSearchCtrl (mvn namespace)New @AuraEnabled(cacheable=true) method getObjectApiNameByRecordId(String recordId) returns the host object's API name so the Quick Search component can resolve the Interaction (Case) lookup at runtime when it is placed on an object other than Interaction (Case).

Lightning components

Lightning component changes are listed in the table below.

Modified Lightning components
Work item(s)ComponentDescription
MIC-3144, MIC-3971medCaseAccountsQuickSearch (mvn namespace)The component is no longer restricted to the Interaction (Case) object. A new caseLookupFieldName design property lets administrators specify the host object's lookup field to Interaction (Case), and the component resolves the host object API name automatically via MED_AccountSearchCtrl.getObjectApiNameByRecordId when the standard @api objectApiName value is not available.
MIC-3144, MIC-3971medNamespaceUtil (mvn namespace)New CASE__CHILD_LOOKUP_FIELD constant (mvn__MED_Case__c) preserves the previous lookup convention when Case Lookup Field API Name is left blank.

Permissions

Permission changes are listed in the table(s) below:

New permission sets
Work itemPermission setDescription
MIC-4318AIMI Option / Ask AIMI (in MIC AIMI Setup)Grants access to the AIMI Option custom metadata records and to the Apex classes that drive the AIMI prompt-selection actions. Administrators must assign this permission set to users who need to run the Ask AIMI actions.
Modified permission sets
Work itemPermission setModification description
MIC-4001MED_Medical_Information_Cloud_AdminAdded Read access to Case.MED_Region__c.
MIC-4001MED_Medical_Information_Cloud_UserAdded Read access to Case.MED_Region__c.
MIC-4191MED_Medical_Information_Cloud_AdminAdded Read and Edit access to MED_Fulfillment__c.MED_Questions__c and MED_Fulfillment__c.MED_Attachments__c.
MIC-4191MED_Medical_Information_Cloud_UserAdded Read and Edit access to MED_Fulfillment__c.MED_Questions__c and MED_Fulfillment__c.MED_Attachments__c.
MIC-4066Admin profileAdded Read access to mvn__MED_Local_Setting__mdt.MED_Template_Case_DDP_Name__c and mvn__MED_Local_Setting__mdt.MED_Template_Final_DDP_Name__c.
MIC-4238MED_Medical_Information_Cloud_AdminGrants read and edit access to the new MED_Run_Presubmit_Validation__c field on Adverse Event and Adverse Event child objects.
MIC-4238MED_Medical_Information_Cloud_UserGrants read and edit access to the new MED_Run_Presubmit_Validation__c field on Adverse Event and Adverse Event child objects.
MIC-4348MED_Manage_Reports_and_Dashboards, MED_View_Reports_and_Dashboards, MED_Create_Personal_Reports_and_DashboardsAdded Dashboards and Reports tabs. Corrected the spelling of the MED_Custom_Response permission set label.
MIC-4251CM_ContentReadOnlyAdded CM_DocumentVersionPackageFileController Apex class access so users with Content - Medical User or Content Read Only permission sets can preview attached files in the Enhanced Document Viewer.
note

Edit access is intentionally not granted on MED_Medical_Information_Cloud_Admin and MED_Medical_Information_Cloud_User; the trigger action manages the value automatically. The System Administrator profile grants Edit access to the field for users who need to override it manually.

Quick actions

Quick action changes are listed in the table below.

New quick actions
Work item(s)ObjectQuick actionDescription
MIC-4066Fulfillment (MED_Fulfillment__c)Prepare Fulfillment (MED_Merge_Cover_Letter)Opens a modal to merge cover letter components into one PDF and case documents into a second PDF.
MIC-4066Fulfillment (MED_Fulfillment__c)Finalize Fulfillment (MED_Finalize_Merge_Letter)Opens a modal to combine the cover letter PDF and the case documents PDF into a single final fulfillment package PDF.

Static resources

Static resource changes are listed in the table below.

Modified static resources
Work item(s)Static resourceModification
MIC-4066MED_PostDeployDataThe data-DDP/ddps.csv seed now includes the Global Case Documents Template and Global Final Template DDP records. The title of the Global Cover Letter Template DDP is updated to "Merged Cover Letter for <<Case_CaseNumber>> - <<Now__g>>". The data-DDP/delivery-options.csv seed now includes corresponding Finalize delivery options that point at the new templates.

Deprecated and deleted items

The following entities are deprecated in the Spring '26 release and will no longer be available or supported in future releases.

Deprecated object fields
Work itemObjectField
MIC-3909MED_AE_Drug_History__cMED_MedDRA_Version_for_Indication__c
MIC-3909MED_AE_Drug_History__cMED_MedDRA_Version_for_Reaction__c
MIC-3909MED_AE_Drug_Information__cMED_MedDRA_Version_for_Indication__c
MIC-3909MED_AE_Medical_History__cMED_MedDRA_Version_for_Medical_History__c
MIC-3909MED_AE_Results__cMED_MeDRA_Version_for_Test_Name__c
note
  • Each of the deprecated fields above has been renamed with a (DEPRECATED) prefix on its Label so that administrators can locate them on existing page layouts. The MedDRA version value is now sourced from the new MedDRA Version (MED_MedDRA_Version__c) field on the MED_E2B_Setting__mdt custom metadata type. See Set the MedDRA version globally for E2B files above.

  • The deprecated fields are still readable and writable in this release so that organizations with existing data can complete their migration on their own timeline. The E2B generator continues to honor a populated record-level value when present. Plan to remove these fields from your layouts and migrate any reporting that depends on them before Mavens removes them in a future release.

Required pre-install and pre-upgrade actions

This section includes the required actions administrators must take before installing or upgrading to the Medical Information Cloud V18 release.

Plan Data 360 prerequisites (only if you intend to enable Data 360)

Data 360 dispatch is a new optional capability in V18. If you plan to route any traffic to Data 360 after upgrading, prepare the following before you author Content Search Settings records:

  • Confirm the Data Cloud DataKit and Data Lake Object (DLO) ingestion that backs Data 360 search is configured and running. The DataKit is a separate prerequisite to Content Search Configuration.
  • Identify the DLO name to use as Search Index. The value must end with _index__dlm.
  • Confirm the Customer Data Platform data space the DLO lives in (typically default).
  • Decide on a minimum search score threshold between 0 and 1 (for example, 0.80).

If you do not plan to enable Data 360, no action is required. With no Content Search Settings records authored, V18 behaves the same as previous releases and every search runs on Einstein.

For configuration guidance, see Content Search Configuration.

Related work item(s): MIC-4568

Confirm DDP templates exist for each country

Before upgrading, administrators must confirm that the Local Setting (mvn__MED_Local_Setting__mdt) record for each country references a valid DDP template in the Template Case DDP Name (MED_Template_Case_DDP_Name__c) and Template Final DDP Name (MED_Template_Final_DDP_Name__c) fields.

The out-of-the-box Default Local Setting (mvn__MED_Local_Setting__mdt) record points these fields at the new Global Case Documents Template and Global Final Template DDP records, which are installed by the Medical Information Cloud - Setup plan in the Install Service (customers running the default configuration do not need to take additional action). Customers who maintain custom Local Setting (mvn__MED_Local_Setting__mdt) records per country must update those records before end users can run the Prepare Fulfillment and Finalize Fulfillment quick actions.

Recommended post-upgrade actions

This section includes the recommended actions administrators should take after upgrading to Medical Information Cloud Spring '26 to enable the new functionality. Each action specifies the criteria for consideration, which details the conditions that must exist to warrant action by a customer.

Set the global MedDRA version on the E2B Setting custom metadata record

If your organization uses MedDRA coding with E2B(R3) submissions and you want every generated file to use a single MedDRA version, set the new MedDRA Version (MED_MedDRA_Version__c) field on the E2B Setting (MED_E2B_Setting__mdt) custom metadata record:

  1. In Setup, open Custom Metadata Types and find the E2B Setting (MED_E2B_Setting__mdt) custom metadata type.

  2. Click Manage Records and open the active E2B Setting record.

  3. Set MedDRA Version to the version your organization uses (for example, 26.0). Use only numbers and the . separator. The field accepts up to four characters per the E2B(R3) 4AN rule.

  4. Save the record.

  5. (Optional) Remove the deprecated record-level MedDRA version fields from any page layouts where you previously surfaced them:

    • MED_AE_Drug_History__c.MED_MedDRA_Version_for_Indication__c
    • MED_AE_Drug_History__c.MED_MedDRA_Version_for_Reaction__c
    • MED_AE_Drug_Information__c.MED_MedDRA_Version_for_Indication__c
    • MED_AE_Medical_History__c.MED_MedDRA_Version_for_Medical_History__c
    • MED_AE_Results__c.MED_MeDRA_Version_for_Test_Name__c
note

You do not have to clear the record-level values on existing Adverse Event child records. While the E2B generator uses the global MedDRA Version as the default, it still honors a populated record-level value when present. This preserves backward compatibility during migration.

Set the sender telecom values on the E2B Setting custom metadata record

If your organization sends E2B(R3) files to a regulator or partner safety system that expects sender telephone, fax, or email elements, set the corresponding fields on the E2B Setting (MED_E2B_Setting__mdt) custom metadata record:

  1. In Setup, open the E2B Setting custom metadata record.

  2. Set Sender Telephone (MED_Sender_Telephone__c) to the sender's telephone number. The generator writes the value as \<telecom value="tel:\<number\>"/\> in element C.3.4.6.

  3. Set the new Sender Fax (MED_Sender_Fax__c) field to the sender's fax number. The generator writes the value as \<telecom value="fax:\<number\>"/\> in element C.3.4.7.

  4. Set Sender Email (MED_Sender_Email_Address__c) to the sender's email address. The generator writes the value as \<telecom value="mailto:\<address\>"/\> in element C.3.4.8.

  5. Save the record.

note

The generator omits the \<telecom\> element entirely when the corresponding setting value is blank. To explicitly signal a missing value with an E2B null flavor, set the field to nullFlavor_\<value\> (for example, nullFlavor_MSK).

Migrate stored Dosage Units and Time Units values (optional)

The Spring '26 picklist updates deactivate the legacy Dosage Units and Time Units labels but do not rewrite existing record values. If your reports or downstream integrations rely on the new labels, you can migrate the stored values:

  1. Identify Adverse Event records that reference a legacy value (for example, run a report on MED_AE_Drug_Information__c filtered by Dosage Units equal to one of the legacy labels listed in Adverse Event picklist values aligned with ICH E2B(R3) above).

  2. Use Data Loader or a Salesforce flow to update each affected record so that Dosage Units or Time Units stores the new label.

  3. Once no record references a legacy value, you can remove the inactive entries from the MED_AE_Dosage_Units and MED_AE_Time_Units global value sets if desired. Mavens recommends leaving the inactive entries in place until you have completed any historical reporting that requires the legacy labels.