Release notes

PJN-829

When two patient accounts and their care plans were merged with the Patient Merge Tool and the child records of the losing care plan were reparented to the winning care plan, none of the child records were populated with the winning patient account aside from Medical History (mvn__PJN_Medical_History__c) records. This was an issue particularly for Member Plan (mvn__PJN_Member_Plan__c) records because the Primary Member Plan (mvn__PJN_Primary_Member_Plan__c) and Secondary Member Plan (mvn__PJN_Secondary_Member_Plan__c) lookup fields on the Care Plan (Case) object had lookup filters that required a Patient (mvn__PJN_Patient__c) value. Since the winning patient was not populated on the member plans, the Patient value on the Member Plan records would be null and cause the entire merge to fail.

All child records of the losing care plan are populated with the winning patient account, including Consent (mvn__PJN_Contact_Point_Type_Consent__c), Event (mvn__PJN_Event__c), Fulfillment Request (mvn__PJN_Fulfillment_Request__c), Member Plan (mvn__PJN_Member_Plan__c), and Prescription (mvn__PJN_Prescription__c) records. Additionally, the lookup filters on the Case object for the primary and secondary member plans, like tertiary member plans, no longer require a patient value. Users can now merge member plans with the Patient Merge Tool even if the patient account on the member plan is not the winning patient.

PJN-1446

The Program Case Dependency (mvn__PJN_Program_Case_Dependency__mdt) custom metadata type configures the dependencies between activities in a care plan stage. Previously, however, if an activity was dependent on multiple other activities, then the dependent activity would be created once every time the controlling activities were either canceled or completed. For example, if Case C was dependent on both Case A and Case B, then Case C would first be created after Case A was closed and then be created again after Case B was closed. This meant that there were duplicate dependent activities based on the number of controlling activities.

The logic behind program case dependencies has been updated. Now, if an activity is dependent on two or more other activities, then the dependent activity would be created after all of the controlling activities have been either canceled or completed. For example, if Case C is dependent on both Case A and Case B, then Case C will only be created after both Case A and Case B are closed. This means that the dependent activity will only be created once for the configured care plan stage.

PJN-1600

When the Contact Information - KCC Before Create Update (mvn__PJN_Contact_Information_Before_Create_Update) flow set the Value (mvn__PJN_Value__c) field on Contact Information (mvn__PJN_Contact_Information__c) records of the Address (PJN_Address) record type, the flow only used commas to concatenate and separate the different address field values. This meant that the generated address did not have proper spacing and was difficult to read (e.g., "123 Main St,The Loop,Chicago,IL,60606").

The flow has been updated to add a space after each comma so that the concatenated address appears more readable (e.g., "123 Main St, The Loop, Chicago, IL, 60606").

PJN-1997

If multiple objects have a record type with the same API name and an Enrollment Wizard Record Form (mvn__PJN_Enrollment_Wizard_Record_Form__mdt) metadata record references the record type API name for one of the objects, the step in the Enrollment Wizard that creates a record of that object would throw a “No form definition found” error, even if none of the other objects are used in the Enrollment Wizard.

The Enrollment Wizard now queries for the object that the record type is on so that it knows what record form to display.

PJN-3315

The ePA Information section in Prior Authorization (mvn__PJN_Prior_Authorization__c) record pages appeared empty for users who did not have electronic prior authorization (ePA) permissions. This was because the fields in the ePA Information section were only visible to users with ePA permissions.

The ePA Information section has been removed, and the fields that were originally in the ePA Information section have been moved to the System Information section in the Prior Authorization page layout.

The Related tab and the right-hand side of the Details tab of Assistance Program (mvn__PJN_Assistance_Program__c) record pages were both empty.

Both tabs have been removed, and the fields that were originally in the Details tab now span the entire width of the Assistance Program FlexiPage.

When users clicked the + Follow button that appeared in the top right corner of every Account record page, the label would change from "+ Follow" to "✓ Following" but nothing else seemed to happen.

The + Follow button was intended to be used with Chatter, which Komodo Care Connect does not utilize, and has therefore been removed from all Account FlexiPages.

PJN-3498

The records in the Events and Shipments related lists on the CarePlan (PJN_CarePlan) Lightning record page were not sorted in a consistent order.

The Event (mvn__PJN_Event__c) and Shipment (mvn__PJN_Shipment__c) records are sorted in descending order by their Name values, similar to how Member Plan (mvn__PJN_Member_Plan__c) and Coverage Investigation (mvn__PJN_Coverage_Investigation__c) records are sorted. Since the Name field is an auto-number field, this ensures that the most recent record appears at the top of the related lists on the Care Plan page.

PJN-3505

Read-only users with the KCC - Read Only - Account Management (PJN_Read_Only_Account_Management) permission set should not have been able to create new Contact Information (mvn__PJN_Contact_Information__c) records but were able to do so with the Contact Information (PJN_ContactInformation) component. The users subsequently encountered error messages when creating the Contact Information records, which were empty, and when opening the related Account records from Account Search.

The New button in the Contact Information component only appears for users who have Create and Edit permissions on the Contact Information object to prevent read-only users from creating empty Contact Information records.

PJN-3581

If a user clicked Create Care Plan in the Enrollment Wizard and then clicked either Cancel or X to close out of the wizard without completing the rest of the enrollment form, the Request (Case) record remained open in its original main tab.

If a user creates a care plan and then immediately exits out of the Enrollment Wizard, the request moves from its main tab into a subtab the same way that it does when a user completes the entire enrollment form.

PJN-3641

Users can create Contact Information (mvn__PJN_Contact_Information__c) records both through Account Search and through the Contact Information (PJN_ContactInformation) component on an Account record page, but the Contact Information fields that were marked as required differed in the two locations. For example, the New Address form in Account Search required users to populate the Address Line 1 and Type fields, but the New Address form in the Person Account record page did not have any required fields.

The same Contact Information page layout for each record type is now used in both Account Search and the Account record pages. In the default page layouts, the Address Line 1 and Type fields are required for Address records, the Email and Type fields are required for Email records, the Fax field is required for Fax records, and the Phone and Type fields are required for Phone records.

PJN-3667

The Start Pre-Install Validation button in the Komodo Install Service (or the Log In to Start Pre-Install Validation button if you have not yet authenticated into a Salesforce org) did not appear to perform any pre-installation check.

The pre-installation validation now checks that the connected Salesforce org is either an Enterprise Edition or an Unlimited Edition. If the connected Salesforce org does not meet this requirement, then the validation will throw an error and Komodo Care Connect cannot be installed.

PJN-3672

If a user tried to merge three patient accounts and created three requests with the Patient Merge Tool, the third patient merge request to be submitted still had the Pending status but would have one or more empty patient accounts. For example, a user may first create a request to merge Patient 1 and Patient 2, then create another request to merge Patient 1 and Patient 3, and then create a third request to merge Patient 2 and Patient 3. If the user submitted the second and third merge requests such that Patient 1 and Patient 2 were both merged into Patient 3 and were therefore the losing accounts, then the two patient accounts in the first merge request no longer existed. However, the first merge request still appeared in the Patient Merge Tool but without any patient accounts.

After Update: Cleanup Orphaned DCRs (PJN_After_Update_Cleanup_Orphaned_DCRs) is a new Trigger Handler Setting (mvn__PJN_Trigger_Handler_Setting__mdt) metadata record that calls the PJN_CancelOrphanedDCRs class to cancel any patient merge requests where one or both patient accounts no longer exist. In the aforementioned example, the status of the first merge request will change from Pending to Cancelled and the request will no longer appear in the Patient Merge Tool.

PJN-3676

When recurring activities were created, the Case Owner (OwnerId) and Program Case DeveloperName (mvn__PJN_Program_Case_DeveloperName__c) fields on the Activity (Case) records were empty, preventing certain functionalities from working as intended.

The Case Owner and Program Case DeveloperName fields have been added to the Recurring Case Clone Fields (mvn__PJN_Recurring_Case_Clone_Fields) field set on the Case object. This ensures that the values from the original activity are stamped on any recurring activities that are created.

PJN-3815

When a patient was enrolled into a care plan, the Program (mvn__PJN_Program__c) field on the Request (Case) record remained empty.

When a patient is enrolled into a care plan, the original request is automatically stamped with the program of the care plan.

PJN-3605

mvn__PJN_Event__c

PJN_External_Enrollment

An enrollment from an external source.