Skip to content
Product Support Cúram

Merative ™ Social Program Management 7.0.4.4 iFix2

Release Notes

Abstract

Merative Social Program Management 7.0.4.4 iFix2 Release Notes

Content

Introduction
System Requirements
Download
Installation
Improvements, Resolved Issues and Third Party Updates
Known Issues
Notices

Introduction

Welcome to the Merative Social Program Management 7.0.4.4 iFix2 release.

This is a cumulative release which incorporates the Improvements, Resolved Issues and Third Party Updates contained in all previous 7.0.4.4 iFix releases. Details of these Improvements, Resolved Issues and Third Party Updates are included separately in the release notes for each of the previous iFix releases. For the latest version of the release notes, see https://curam-spm-devops.github.io/wh-support-docs/spm/release-notes.

Full product documentation can be found in the Product documentation and PDFs.

System Requirements

For information about the supported software and hardware for this release, see the Merative Social Program Management Prerequisites.

Download

See the download instructions for this release at /support/curam.

Installation

Before running the installer please ensure all files in your Merative Social Program Management installation are writable.

The installation steps are as follows:

  • Extract the contents of the .zip file to a local drive location.
  • Run the Merative Social Program Management installer, which can be found in the INSTALLER folder at that location.
  • After installing, the appropriate build targets must be run as necessary for your installation.

Additional installation instructions can be found in the Development Environment Installation Guide.

Upgrading

If you are upgrading from a previous version, the Merative Social Program Management Upgrade Helper contains documentation and tooling to help you to upgrade your Merative Social Program Management application codebase and database to work with your new version of Merative Social Program Management. The Merative Social Program Management Upgrade Guide describes a recommended process for performing application and database upgrades. The Upgrade Helper contains tools to assist you with implementing the upgrade, including tooling to produce a schedule of required migrations for your upgrade, tooling to provide information about database schema changes and tooling to generate initial SQL scripts for applying changes to your database.

To download the appropriate version of the Merative Social Program Management Upgrade Helper, see the download instructions at /support/spm.

Improvements, Resolved Issues and Third Party Updates

Third Party Updates

WorkItem:257684 - Update the versions of the Jackson JARs

The Jackson API contains multiple functions to read and build JSON using Java. It has very powerful data binding capabilities and provides a framework to serialize custom Java objects to JSON strings and deserialize JSON strings back into Java objects. The Java Development Environment (JDE) and the REST infrastructure utilize these utilities.
The versions of these JARs have now been updated from 2.9.9 and 2.9.10.1 to 2.10.2. As a result of this upgrade, the following changes have been made in the JDE and REST deliverables.

  • ../CuramSDEJ/lib/third_party_version.properties - the versions of the specified Jackson JARs have been updated.
  • ../CuramSDEJ/lib/jackson-annotations-2.10.2.jar - new JAR added.
  • ../CuramSDEJ/lib/jackson-core-2.10.2.jar - new JAR added.
  • ../CuramSDEJ/lib/jackson-databind-2.10.2.jar - new JAR added.
  • ../CuramSDEJ/lib/jackson-annotations-2.9.9.jar - old JAR removed.
  • ../CuramSDEJ/lib/jackson-core-2.9.9.jar - old JAR removed.
  • ../CuramSDEJ/lib/jackson-databind-2.9.10.1.jar - old JAR removed.
  • ../CuramCDEJ/lib/ext/jar/jackson-annotations-2.10.2.jar - new JAR added.
  • ../CuramCDEJ/lib/ext/jar/jackson-core-2.10.2.jar - new JAR added.
  • ../CuramCDEJ/lib/ext/jar/jackson-databind-2.10.2.jar - new JAR added.
  • ../CuramCDEJ/lib/ext/jar/jackson-annotations-2.9.9.jar - old JAR removed.
  • ../CuramCDEJ/lib/ext/jar/jackson-core-2.9.9.jar - old JAR removed.
  • ../CuramCDEJ/lib/ext/jar/jackson-databind-2.9.10.1.jar - old JAR removed.
  • ../EJBServer/components/Rest/restlib/dependencyLibsExt/jackson-annotations-2.10.2.jar - new JAR added.
  • ../EJBServer/components/Rest/restlib/dependencyLibsExt/jackson
    -core-2.10.2.jar - new JAR added.
  • ../EJBServer/components/Rest/restlib/dependencyLibsExt/jackson-databind-2.10.2.jar - new JAR added.
  • ../EJBServer/components/Rest/restlib/dependencyLibsExt/jackson-annotations-2.9.9.jar - old JAR removed.
  • ../EJBServer/components/Rest/restlib/dependencyLibsExt/jackson
    -core-2.9.9.jar - old JAR removed.
  • ../EJBServer/components/Rest/restlib/dependencyLibsExt/jackson-databind-2.9.10.1.jar - old JAR removed.

Cúram Enterprise Framework

Dynamic Evidence

EVIDENCE MAINTENANCE

WorkItem:259181 - Dynamic evidence not recognising end date of a record in a succession

Issue Description:

When an evidence record of a particular type was not end dated manually by a caseworker but was instead succeeded by a new evidence record of another type, the caseworker was subsequently prevented from creating a new evidence record of the original type.

Dynamic Evidence did not recognize records in a succession as separate contiguous records. In essence, the dynamic evidence maintenance processing did not recognize the effective from date of the next record in the succession minus one day as the virtual, or notional end date of a record in that succession. This led to problems when creating new evidence, where validations were sometimes thrown stating that a record already existed for the period of the new record. This was due to the system recognizing the records in the succession as being open-ended.

User Interface Impact: No

Steps to Reproduce:

An example of this issue occurs in the Healthcare Reform Solution for Tax Filing Status evidence. When a Tax Filing Status evidence record of a particular type was not end dated manually by a caseworker but was instead succeeded by a new Tax Filing Status evidence record of another type, the caseworker was subsequently prevented from creating a new evidence record of the original type.

The caseworker originally recorded the individual as a 'tax filer'. Circumstances changed and the individual became a 'non-filer'. The caseworker updated the existing 'tax filer' record and changed the type to 'non-filer' and set the effective date of the change. Subsequently, the individual left the household and the caseworker end-dated their Tax Filing Status evidence record. Sometime later the individual rejoined the household as a tax filer. The caseworker was unable to create a new Tax Filing Status evidence record of type 'tax filer'. A duplicate validation was thrown stating a Tax Filing Status evidence record of type 'tax filer' already exists.

This was happening due to dynamic evidence processing not recognizing the virtual end date of a record in a succession. The virtual or notional end date is the effective from date of the next record in the succession minus one day.

  1. Login as an Insurance Affordability caseworker.
  2. Create an Insurance Affordability application for a tax filer with an income of $20,000 and an application date of 8/7/2017.
  3. Submit and authorize the application.
  4. Edit the Tax Filing Status record of 'Tax Filer' and set the effective date to 9/1/2017 and change type to 'Non-Filer'.
    • Apply changes.
  5. End date the Tax Filing Status record of ‘Non-Filer’ to 9/20/2017.
    • Apply changes.
  6. Create a new Tax Filing Status record of type ‘Non-Filer’, with start date 9/21/2017.
    • Apply changes.
  7. End date the Tax Filing Status record of ‘Non-Filer’ to 9/24/2017.
    • Apply changes.
  8. Create a new Tax Filing Status record of type ‘Tax Filer’, with start date 9/25/2017.
  9. The following validation error is displayed and prevents the user from creating the new Tax Filing Status record: ‘A Tax Filing Status record of ‘Tax Filer’ already exits for this Participant for the same period’.

Resolution:

Dynamic evidence processing has been updated to recognize the virtual, or notional end date of each record in a succession thereby building up a list of contiguous records against which the creation of any new record of the same type will be validated. The caseworker can now create a new evidence record of the same type as one that has been succeeded.

EVIDENCE VALIDATIONS

WorkItem:257622 - A verification informational message prevents a user from continuing when creating SSN Identifications for a person

Issue Description:

A verification informational message can display when creating evidence with verifications configured for it. An example is when creating Identifications of type Social Security number evidence for a person which prevents the user from continuing. The message is 'The following items require verification:'. Another example is on validating mailing addresses when registering a prospect person.

User Interface Impact: No

Related WorkItem(s): 259181

Prerequisite(s):

  1. Login as a system administrator.
  2. Navigate to Code Tables under Application Data in the shortcuts panel.
  3. Search for the name: VerReqUsageName.
  4. Select the New Item row-level action.
  5. Enter the following details:
    • Item Name: Participant Data Case
    • Technical ID (code): VRUN9999
  6. Click Save.
  7. Publish the changes using the page action.
  8. Login as an administrator.
  9. Navigate to Configured Verifications under Verifications in the shortcuts panel.
  10. Click on SSNID under Personal.
  11. Select the Edit page action and change the Evidence Type from SSN Details to Identifications.
  12. Click Save.
  13. Click on Social Security Card under items, which is under SSNID in the tree view.
  14. Select the Edit page action and change Usage Type to Shared, Level to 1 and check Mandatory.
  15. Click Save.
  16. Click on requirements under SSNID and select New from the page action menu. Enter the following details:
    • Name: Requirement 1
    • Level: 1
    • From Date: 1/23/2020
    • Minimum Items: 0
    • Reverification Mode: Reverify Always
    • Supplied By Client: Unchecked
    • Mandatory: Checked
    • Due Days: 0
    • Warning Days: 0
  17. Click Save.
  18. Click on Requirement 1 under Requirements.
  19. Select Apply To from the page action menu. Enter the following details:
    • Name: Participant Data Case
    • Applies To: Select 'Non Case Data' in the drop-down and use the search to select Participant.
  20. Click Save.

Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Evidence tab.
  4. Select New from the page action menu and create Identifications evidence with the following details:
    • ID Reference: any 9-digit SSN
    • Type: Social Security Number
    • Preferred: Checked
  5. Click either Save & Exit or Save & Next.
  6. Issue: The following informational message is displayed and the user cannot continue 'The changes that you have made may affect the verification information recorded for the following item(s):'.

Resolution:

There was an issue in the code that was unintentionally throwing the verification informational at the point of creating the evidence when it should be ignored at that stage. This has now been resolved.

PO08703, WorkItem:257682 - A comparison validation with multiple clauses in a Dynamic Evidence definition gets cached repeatedly in memory at run time resulting in the heap space being exhausted

Issue Description:

If a Dynamic Evidence type definition includes a validation which has a comparison validation containing multiple clauses, duplicate copies of this configuration information will be repeatedly added to a list in memory each time the validation executes.

Each time one of the affected validations succeeds, the configuration information gets added to the list in memory once more and persists there. However, each time one of them fails, this list in memory multiplies in size. All users who encounter the affected validation will contribute to this memory issue. This leads to a rapid increase in heap usage and eventually exhausts all the heap space available resulting in the server crashing or becoming unresponsive.

User Interface Impact: No

Prerequisite(s):

This issue only affects Dynamic Evidence with comparison validations which have multiple clauses. The following example describes how to configure such a validator.

  1. Login as an administrator.
  2. Navigate to Dynamic Evidence under Rules and Evidence in the shortcuts panel.
  3. Locate an evidence type that contains an integer attribute.
  4. Select one of the Evidence Type Versions and choose New In Edit Copy specifying an effective from date.
  5. For this new version, select the Edit Metadata row-level action.
  6. On the Evidence Properties panel of the evidence editor, click on the Validations tab.
  7. Click Add to add a new Comparison validation. Specify the required fields for the validation details. Ensure Use Literal and Multiple Clauses are checked.
  8. Add two Clauses to the validation.
  9. Choose the Conjunction (Any or All) and click Save.
  10. Save the evidence type version in the editor.
  11. Activate the new Evidence Type Version from the row-level menu on the Dynamic Evidence list page.

Steps to Reproduce:

  1. Login as a caseworker.
  2. Navigate to a case for which the evidence type is configured.
  3. Add an instance of the evidence type to the case.
  4. Specify an invalid value for the attribute that has the comparison validation. Try to save the evidence.
  5. The previously configured validation message is displayed correctly.
  6. Try to save the evidence again.
  7. Issue: Multiple copies of the same validation message will be displayed on the screen, due to the multiple copies of the configuration data stored in memory on the server. The number of validation messages will increase significantly with each attempt to save the evidence. In a worst-case scenario, the heap space on the server will be exhausted, resulting in the server crashing or becoming unresponsive.

Resolution:

The configuration data for comparison validators in Dynamic Evidence is now only processed once and duplicates are no longer loaded into memory.

Cúram Modules

Evidence Broker

PO08478, WorkItem:251363 - Sharing successions when using custom data matching can result in two successions on the timeline with null effective dates

Issue Description:

The initial record in a timeline of evidence has a null effective date, the business start date is used to start the timeline. When processing incoming evidence into an existing timeline of evidence, the incoming initial record cannot be left with a null effective date otherwise the timeline is broken as it is not sequential. When using custom matching in evidence broker, the incoming initial record was created with a null effective date.

User Interface Impact: No

Prerequisite(s):

  1. Ensure there is no evidence sharing configured for Insurance Affordability integrated case to Insurance Affordability integrated case for Income evidence.
  2. Configure an implementation of the AESCustomDataMatching hook for income evidence to set the business object resolution (BOR) action to Modify.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new person.
  3. Submit an application with an application date of 1/1/2019.
  4. Authorise the application to create an integrated case.
  5. Submit a second application with a date of 6/1/2019.
  6. Authorise this application to create a second integrated case.
  7. On the first integrated case add Income evidence with a start date of 1/1/2019 and an amount of 100.
  8. Verify the outstanding Income verification and apply changes.
  9. Login as an administrator and configure evidence sharing from Insurance Affordability integrated case to Insurance Affordability integrated case for Income with Trusted Source set to Yes and Share Verifications set to Always.
  10. Login as an Insurance Affordability caseworker.
  11. Add Income evidence to the second integrated case with a start date of 6/1/2019 and an amount of 600.
  12. Verify the outstanding Income verification and apply changes.
  13. Navigate to the first integrated case.
  14. Issue: A succession for the income evidence is created but it has the same effective from date of null as the first record in the succession, which is incorrect.

Resolution:

This issue was caused when forming the new evidence descriptor on the target case. The effective date was not set correctly. This is resolved and the effective date is now set correctly. When performing custom matching, if an effective date is not set on the source record, the evidence start date is used as the effective date to prevent a succession being created with a null effective date.

WorkItem:251846 - Unhandled server exception on the incoming evidence list with Paid Employment / Earned Income logically equivalent configuration

Issue Description:

An unhandled server exception occurs when Income evidence on an Insurance Affordability integrated case is shared to Paid Employment & Earned Income on an Income Support integrated case, and then both of these are subsequently pulled onto a new Income Support integrated case. When the user accesses the incoming evidence list on the second Income Support integrated case an unhandled server exception is thrown.

User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure a new evidence sharing configuration with the following details:
    • Select Income Support as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • Select the evidence types Paid Employment and Earned Income.
    • Share Verifications = Never, Trusted Source = Yes.
  4. Click Save and Exit.
  5. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Income as the source evidence type and Paid Employment as the target evidence type.
    • Share Verifications = Never, Trusted Source = Yes.
    • Browse and upload the sample XML file from DeveloperWorks (HCRIncome_CGISSPaidEmployment.xml). This file maps income type of 'Wages and Salaries' only.
  6. Click Save and Exit.
  7. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Income as the source evidence type and Earned Income as the target evidence type.
    • Share Verifications = Never, Trusted Source = Yes.
    • Browse and upload the sample XML file from DeveloperWorks (HCRIncome_CGISSEarnedIncome.xml). This file maps income type of 'Wages and Salaries' only.
  8. Click Save and Exit.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Add participant details of employment for the person.
  4. Create a new Insurance Affordability application for the person, adding two separate Incomes of type Wages and Salaries.
  5. Authorize the application.
  6. Login as an Income Support caseworker.
  7. Create a new Income Support case for the person.
  8. Navigate to the incoming evidence list on this Income Support integrated case.
  9. Observe there are two business objects of Paid Employment and Earned Income evidence.
  10. Add one set of Paid Employment and Earned Income from the incoming evidence list to the case and set the employment type to part-time on the Paid Employment evidence.
  11. Apply changes.
  12. Navigate back to the incoming evidence list.
  13. Use the 'Reject as Not Required' the other Paid Employment and Earned Income records.
  14. Create a new Income Support integrated case for the person.
  15. Navigate to the incoming evidence list for this Income Support integrated case.
  16. Expand one of the incoming Paid Employment and Earned Income business objects.
  17. Issue: An unhandled server exception occurs on this page.

Resolution:

This issue has been resolved by updating the Evidence Relationship logic to ensure that a relationship cannot be created between two evidence records of the same type. This will prevent the infinite loop and the resultant unhandled server exception when the business objects are being constructed to present to the user on the incoming evidence list.

Technical:

The underlying cause of the problem in the reported issue has to do with the sharing logic. During sharing, the sharedInstanceID on the Income record makes its way onto both the Paid Employment and Earned Income evidence descriptors on the target case.

The issue arises when a second Income Support integrated case is created. This pulls the Paid Employment / Earned Income business object from the first Income Support integrated case. However, when evidence is shared, the system needs to look up the source case to see if it's part of a parent-child relationship, and it looks up the Evidence Relationship table to achieve this. In this instance, the sharedInstanceID on the parent and child are the same. This means that when the system looks up the source case by sharedInstanceID, it will find both records. This ultimately results in an Evidence Relationship record being created between either a parent-parent or child-child. When a user clicks on the Incoming Evidence page, the system tries to construct these objects to display to the user, but because a parent-parent or child-child Evidence Relationship exists, the system gets stuck in an infinite loop.

The issue has been addressed by preventing an Evidence Relationship from being created between two evidence records of the same type.

WorkItem:252462 - Records merged from the incoming evidence list can have different start dates resulting in rule propagation errors when the evidence is activated

Issue Description:

Rules propagation expects that the timeline for an evidence business object starts by using the business start date and changes over time-based on the effective date. Rules validate these dates by checking the start date is consistent across all records in the succession on the timeline. An evidence timeline that is constructed by the ‘Set as Latest of Incoming’ action from the incoming evidence list can fail this rules validation. The rules validation failure occurs when the start date of evidence on the incoming evidence timeline differs from the start date of evidence on the existing evidence timeline. The start date is not validated or updated as part of merging the two timelines together during the ‘Set as Latest of Incoming’ action. Also, when custom matching is used to perform a modify operation on the target case, a timeline can be formed with different start dates leading to the same rules validation.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a Person and select New Application from the tab menu.
  3. Navigate through the application script ensuring to add income for 2000 with a start date in the past, 1/8/2019, for example.
  4. Complete the script and authorize the application.
  5. Open the integrated case and perform two successions on the income record by effective dating it, 3200 on 10/8/2019 and 3400 on 20/8/2019, for example.
  6. Apply changes.
  7. Create another application for the same person. This time add an income with a start date of today’s date of the same type with a different amount than already entered.
  8. On the new application case, navigate to the incoming evidence list page and there should be income evidence listed.
  9. Select the third record in the succession and select 'Set as Latest of Incoming'.
  10. Select the record on the next screen and click Next.
  11. Select New Version and enter an effective date of today’s date and click Next.
  12. The Edit Income modal opens and is populated with the income details. Note that the start date is set to today’s date.
  13. Click Save.
  14. Issue: The record is saved and now there are rule propagation warnings in the system log/s because the start dates on the income evidence succession are different. Three records in the succession have a start date of 1/8/2019 and the current one has a start date of today's date.

Resolution:

When using the action 'Set as Latest of Incoming', where there are different start dates on the incoming and existing lists, evidence sharing now automatically sets the start date to the earliest start date between the two lists. The records from both sides will be in the same evidence succession set, all having the same start date. The informational message on the first page of the 'Set as Latest of Incoming' wizard has been updated to notify caseworkers of this behaviour.

Technical:

The Succession processor has been updated to align the start dates across the timeline for any records that it processes. The Succession processor will continue to only allow successions to be created after the start date of the existing evidence timeline. This means that evidence cannot be added to a timeline using the Modify action unless it has an effective date which is later than the start date of the succession set. When using Custom Data Matching, the source record may not have an effective date. In this scenario, the Succession processor will use the start date of the source record as the effective date as long as it is after the target start date.

When merging timelines on a case, the 'Set as Latest of Incoming' logic will now find the earliest start date in the succession set and update all records to use that value. This means that the start date value entered in the modal may actually be ignored and the system will determine what start date to use. If the user has entered a start date that is earlier than all other start dates in the succession set, this one will be used instead. These records can still be changed before they are activated.

PO08690, WorkItem:255517 - Evidence shared using custom matching to recommend a Modify system action is not correctly sharing verifications to the target case

Issue Description:

When using custom matching in the Evidence Broker to perform a succession, verifications that are already verified are not being shared and this prevents the evidence from being auto-activated on the target case.

User Interface Impact: No

Prerequisite(s):

  1. Ensure there is no evidence sharing configured for Insurance Affordability integrated case to Insurance Affordability integrated case for Income evidence.
  2. Configure an implementation of the AESCustomDataMatching hook for income evidence to set the business object resolution (BOR) action to Modify.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new person.
  3. Submit an application with an application date of 1/1/2019.
  4. Authorise the application to create an integrated case.
  5. Submit a second application with a date of 6/1/2019.
  6. Authorise this application to create a second integrated case.
  7. On the first integrated case add income evidence with a start date of 1/1/2019 and an amount of 100.
  8. Verify the outstanding Income verification and apply changes.
  9. Login as an administrator and configure evidence sharing from Insurance Affordability integrated case to Insurance Affordability integrated case for Income with Trusted Source set to Yes and Share Verifications set to Always.
  10. Login as an Insurance Affordability caseworker.
  11. Add Income evidence to the second integrated case with a start date of 6/1/2019 and an amount of 600.
  12. Verify the outstanding Income verification and apply changes.
  13. Issue: Navigate to the first integrated case and the Income evidence is appearing as in-edit and verifications are not verified.

Resolution:

This issue was caused when forming the new evidence descriptor on the target case. This has been fixed and the verifications are now sharing correctly when custom matching is used.

PO08708, WorkItem:257406 - Error stating Tax Filing Status must be specified on apply changes although the evidence exists as active evidence

Issue Description:

When a parent-child business object is shared to a target case, where the parent object was previously shared to that same target case, only the child record is shared. This can result in a validation being thrown, as the child now exists on the target and is not linked to a parent.

An example of where this can occur is in sharing of a Tax Filing Status to Tax Relationship parent-child business object where the Tax Filing Status was already brokered to the target case. In this business scenario, the following error message will be thrown when activating evidence on the target:

'Parent evidence Tax Filing Status must be specified.'

User Interface Impact: No

Prerequisite(s):

  1. Ensure that sharing configurations exist for all evidence between the Insurance Affordability application and Insurance Affordability integrated case with Trusted Source set to Yes and Share Verifications set to Always.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a Person (Adult).
  3. Create an Insurance Affordability application for the Adult and set the Adult as a tax filer.
  4. Authorize the application.
  5. Register a Person (Child).
  6. Create another Insurance Affordability application for the Adult with a few differences. Set Adult as tax filer, and add Child as a household member. Set Adult as the parent of Child and Adult is also a tax filer for Child.
  7. Authorize the application and choose to reuse the existing Insurance Affordability integrated case.
  8. Navigate to the integrated case and apply changes.
  9. Issue: Observe the validation 'Parent evidence Tax Filing Status must be specified' appears although the evidence exists in Active Evidence.

Resolution:

This was resolved by checking if the source parent has been matched to a parent on the target case with a business object resolution (BOR) action of Ignore (Link). If it has, then a relationship is created between the child and the existing (linked) parent on the target case.

In the scenario outlined here, the Tax Filing Status record that forms the Tax Filing Status to Tax Relationship business object is recommended a business object resolution (BOR) action of Ignore (Link), as it is identical to the existing active Tax Filing Status on the case. As part of this, it is linked to the existing active record. When the Tax Relationship is processed, the functionality for managing the Evidence Relationships now looks up the records matched against the ignored parent and creates the necessary parent-child relationships to those.

PO08710, WorkItem:257497 - Deleted child evidence from a source integrated case is not sharing to the target integrated case

Issue Description:

When parent-child evidence exists on an integrated case, the caseworker may decide to delete the child evidence. When this happens, and the child evidence is configured for sharing, the deleted evidence is not shared to a target case.

User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure Evidence Sharing with Trusted Source set to Yes between two Insurance Affordability integrated cases for the following evidence:
    • Application Filer
    • Application Filer Consent
  4. Click Save and Exit.

Steps to Reproduce:

  1. Login as Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an application for the person, specifying that they file taxes but have no income.
  4. Authorize the application.
  5. Navigate to the newly created integrated case and activate the evidence.
  6. Repeat step 3 and create another application for the Person.
  7. Authorize this application to create a second integrated case.
  8. Navigate to the second integrated case and activate any evidence.
  9. Modify the Application Filer and Application Filer Consent evidence on the first integrated case by adding end dates.
  10. Apply changes.
  11. Navigate to the incoming evidence list on the second integrated case.
  12. Add the incoming Application Filer and Application Filer Consent evidence from the first integrated case and apply changes.
  13. Delete the Application Filer Consent evidence on the first integrated case and apply changes.
  14. Issue: The Application Filer Consent evidence is not deleted from the second integrated case.

Resolution:

This issue has been resolved and the logic now considers canceled child records that are being actioned as part of the current apply changes operation and shares them correctly.

Technical:

The logic to create a business object to share works on a 'top-down' perspective. This means that when child evidence is deleted and activated, the evidence broker firstly retrieves the parent evidence and from there forms the business object by retrieving the children, grandchildren, etc. However, it did not consider canceled (child) records which meant that the child was never added to the business object to be considered for sharing. This is now resolved by considering canceled child records when building the business object to be shared.

WorkItem:257631 - Duplicate verification items are being added to verifications when evidence is shared as a correction or succession

Issue Description:

When verifications are configured to be shared, there is an issue where the number of verification items that are added to shared verifications increases incorrectly. This issue occurs for corrections and successions and results in the display of several duplicate verification items.

**User Interface Impact: **No
Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure identical sharing with Trusted Source set to Yes and Share Verifications set to Always between Insurance Affordability integrated case and Insurance Affordability integrated case for Income evidence.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an Insurance Affordability application for the person.
  4. Authorize the application.
  5. Create a second Insurance Affordability application for the person.
  6. Authorize the second application to create a second integrated case.
  7. Navigate to the evidence dashboard of the first Insurance Affordability integrated case. Create Income evidence with the following values:
    • Type: Wages & Salaries
    • Amount: 100
    • Frequency: Yearly
    • Source: Manual
    • Start Date: 1/1/2010
  8. Add proof to the outstanding Verification to mark it as verified and apply changes.
  9. Navigate to the active evidence list on the second integrated case. Verify that the Income has shared correctly and is verified.
  10. Navigate back to the first integrated case and update the previous Income evidence to have an effective date of 1/1/2015 and an amount of 200.
  11. Add a different type of proof to the outstanding Verification to mark it as verified and apply changes.
  12. Navigate to the active evidence list on the second integrated case. Verify that the Income has shared correctly and is verified.
  13. Issue: The Verification proof has been duplicated during sharing and added multiple times to the verifications list on the target integrated case.

Resolution:

This issue was caused by how the verification items were retrieved from the source case. This issue has been fixed and now the system only shares the verification item associated with the current evidence being shared.

PO08724, WorkItem:257929 - Unhandled Server Exception on incoming evidence list after enabling Advanced Evidence Sharing

Issue Description:

When navigating to the incoming evidence list of an Insurance Affordability integrated case with Advanced Evidence Sharing enabled, an unhandled server exception occurs when reading address evidence that was created in resilience mode by the deprecated evidence broker. Resilience mode is a mechanism used in evidence sharing to ensure evidence is still delivered to a case via the incoming evidence list after there were errors trying to automatically accept the evidence.

User Interface Impact: No

Prerequisite(s):

  1. Login as a system administrator.
  2. Navigate to Property Administration under Application Data in the shortcuts panel.
  3. Search for the property 'curam.aes.advancedEvidenceSharingEnabled' and ensure its value is set to NO so that the old evidence broker is invoked.
  4. Click Publish if the value needed to be changed.
  5. Login as an administrator.
  6. Navigate to Sections under User Interface in the shortcuts panel.
  7. Locate the section with ID ADMINAPPSection and click on it to open it.
  8. Click on the Tabs tab and use the Add page action to search for and add the tab with the name EvidenceBroker.
  9. Click on the Shortcuts Panel tab and locate the Group with ID RulesAndEvidence.
  10. Use the toggle to drill in and view the links associated with the RulesAndEvidence group.
  11. For the entry with Link ID AdvancedEvidenceSharing, use the Edit row-level action to update the Page ID to EvidenceBroker_listIdenticalSharedEvidenceConfig, making note of the Page ID that was there.
  12. Publish the changes using the Publish link under User Interface in the shortcuts panel.
  13. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  14. Use the New page action to set up the following identical sharing configuration for Address evidence, if they don't already exist, with Auto Accept and Auto Activate both selected:
    • Insurance Affordability (Application Case) to Insurance Affordability (Integrated Case)
    • Person to Insurance Affordability (Application Case)
    • Person to Insurance Affordability (Integrated Case)
    • Insurance Affordability (Integrated Case) to Person

Note:

To undo the changes above, make sure to:

  1. Remove the newly added EvidenceBroker tab added at step 8 above.
  2. Revert back to the old Page ID that was overwritten by EvidenceBroker_listIdenticalSharedEvidenceConfig at step 11 above.
  3. Publish the changes using the Publish link under User Interface in the shortcuts panel.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an Insurance Affordability application case for the Person.
  4. Authorize the Insurance Affordability application case to create the Insurance Affordability integrated case.
  5. Repeat the last two steps so that the Person has three authorized application cases and three integrated cases.
  6. Login as a system administrator.
  7. Navigate to Property Administration under Application Data in the shortcuts panel.
  8. Search for the property 'curam.aes.advancedEvidenceSharingEnabled' and update its value to YES.
  9. Click Publish.
  10. Login as an Insurance Affordability caseworker.
  11. Navigate to the incoming evidence list of the most recently created integrated case.
  12. Issue: An unhandled server exception occurs.

Resolution:

This was caused by the logic in the incoming evidence list not correctly handling empty list data that was created by the old evidence broker. This issue has been fixed and the incoming evidence list on the new evidence broker now displays the data correctly.

PO08730, WorkItem:258099 - Unhandled server exception on the incoming evidence list on expanding the incoming Absent Parent business object

Issue Description:

When an Absent Parent business object, which consists of Absent Parent, Child Support Enforcement, Absent Parent Child Support, and Absenteeism records, is shared to the incoming evidence list of a case with an existing Absent Parent business object, an unhandled server exception is thrown when the caseworker expands the Absent Parent business object.

Specifically, the exception is thrown when the existing Absent Parent business object, which consists of the same four evidence types, Absent Parent, Child Support Enforcement, Absent Parent Child Support, and Absenteeism, has an in-edit effective-dated change on the Child Support Enforcement evidence.

User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure Evidence Sharing with Trusted Source set to Yes between two Income Support integrated cases for the following evidence types:
    • Absent Parent
    • Absent Parent Child Support
    • Child Support Enforcement
    • Absenteeism
  4. Click Save and Exit.

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a new Person.
  3. Select New Application from the person tab.
  4. Create and submit an application case for Medical Assistance, backdated 1 year ago for the person ensuring to add a child in the script.
  5. Navigate to the newly created income support application.
  6. Navigate to the evidence dashboard add the following evidence types in the following order:
    • Absent Parent
    • Absent Parent Child Support
    • Child Support Enforcement
    • Absenteeism
  7. Apply changes.
  8. Create and submit a second application case for Medical Assistance, backdated 6 months ago for the person.
  9. Navigate to the newly created income support application.
  10. Use the Guided Change wizard to add the child from the first application as a member on the second application.
  11. Navigate to evidence dashboard add the following evidence types in the following order:
    • Absent Parent
    • Absent Parent Child Support
    • Child Support Enforcement
    • Absenteeism
  12. Apply changes.
  13. Make an effective-dated change to Child Support Enforcement on the second application but leave it in-edit.
  14. Navigate to the incoming evidence list on the second income support application and expand the Absent Parent business object.
  15. Issue: An unhandled server exception is encountered.

Resolution:

This issue has been resolved and there is no longer an unhandled server exception experienced when performing the above scenario.

Technical:

The underlying problem here was a ConcurrentModificationException being thrown when the Absent Parent business object to be displayed was been constructed. This happened as the Absent Parent business object that was being iterated over was increased in size during this iteration process. This issue is now resolved and the unhandled server exception is no longer thrown.

PO08733, WorkItem:258133 - Business objects that include Ownership evidence are always recommended a manual intervention even if Trusted Source is set to Yes

Issue Description:

When any business object containing Ownership evidence is shared from one Income Support integrated case to another Income Support integrated case, the evidence always appears in the incoming evidence list even if Trusted Source is set to Yes. An example of where this occurs is in the sharing of Liquid Resource and Ownership evidence.User Interface Impact: No

Prerequisite(s):

This issue occurs when sharing any evidence that uses Ownership, such as Burial Plan, Burial Plot, Liquid Resource, Property, Vehicle. The steps below reference Liquid Resource and Ownership only as an example.

Verify/create sharing configurations for the following evidence:

  • Income Support to Income Support.
  • Trusted Source = Yes.
  • Evidence types: Ownership, Liquid Resource.

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a new Person.
  3. Submit two separate applications (FNS/SNAP and Cash Assistance). Two Income Support integrated cases will be created.
  4. From one of the Income Support integrated cases, add Liquid Resource and Ownership evidence.
  5. Verify and apply changes.
  6. Review the second Income Support integrated case for the shared evidence.
  7. Issue: The evidence is appearing on the incoming evidence list.

Resolution:

The issue above arose as the case participant role on the Ownership evidence is of type 'Ownership'. There is no case participant role on the Liquid Resource evidence. In this instance, evidence always shared with a business object resolution (BOR) action of Manual Intervention as there is no Primary or Member case participant on the business object.

To address this, the sharing logic now checks if the case participant role, which is of type 'Ownership' in the scenario above, also exists as a member (Primary or Member) on the source case and, if so, will recommend an Insert on the target case as opposed to a Manual Intervention. This means that when Trusted Source is set to Yes for the shared evidence types, the evidence can be automatically activated.

It is important to note that some evidence types such as Loan, Annuity, Shelter & Utility and General Insurance will have case participant roles such as Institutions that will not exist as a member on the case. In this instance, these evidence types will correctly share to the incoming evidence list on the target case.

WorkItem:259219 - Incoming evidence that has been shared as a deletion disappears after refreshing the page

Issue Description:

During evidence sharing with Trusted Source set to No, when evidence is deleted and shared to another case it appears on the incoming evidence list. If the existing evidence is linked to and is identical to the incoming deleted evidence, refreshing the incoming evidence list results in the deleted evidence disappearing from the list.

User Interface Impact: No

Prerequisite(s):

  1. Login in as an administrator.
  2. Configure identical evidence sharing for Application Filer and Application Filer Consent evidence from Insurance Affordability integrated case to Insurance Affordability integrated case. Ensure that Trusted Source is No for both.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create and authorize a new application.
  4. Create a second application for the same person.
  5. Authorize the second application to create a second integrated case.
  6. Review both integrated cases for incoming evidence. If there is any on either case, select the 'Reject as not required' option.
  7. Navigate to the first integrated case and modify Application Filer and Application Filer Consent evidence by adding end dates.
  8. Apply changes.
  9. Navigate to the incoming evidence list on the second integrated case.
  10. Choose the option 'Update with incoming' for both Application Filer and Application Filer Consent. Choose the option 'Correction' when prompted. Apply changes.
  11. Navigate back to the first integrated case and delete the Application Filer Consent evidence. Apply changes.
  12. Issue: On the second integrated case there is incoming evidence for the deleted Application Filer Consent, but when the incoming evidence list is refreshed the evidence disappears.

Resolution:

The incoming evidence list contains processing to set evidence to be discarded when it is identical to existing evidence on the case. This processing has been updated to allow the display of identical evidence if the incoming record is a deletion so that a user can now action that evidence.

WorkItem:259555 - The sharing of Person Relationships evidence from an integrated case back to the respective Person level evidence fails

Issue Description:

The sharing of PDC Relationships evidence from an integrated case back to the respective Person level evidence fails. The server logs indicate that a null pointer exception is thrown which is preventing the process from completing successfully.

**User Interface Impact: **No

Prerequisite(s):

  1. Login as an administrator.
  2. Click on the Administration Workspace tab.
  3. Expand the shortcuts panel and click on Integrated Cases under Case.
  4. Click on any of the integrated cases.
  5. Click on the Evidence tab to see the evidence types configured against the integrated case.
  6. If Relationships evidence is not listed, click on the Add Evidence page action.
  7. Select Relationships in the Evidence Type drop-down and click Save.
  8. Click on Evidence Sharing under Rules and Evidence in the shortcuts panel.
  9. Select the New Sharing Configurations tab menu option.
  10. On the Select Source and Target page, select the integrated case from above as the source and Person as the target.
  11. Click Next.
  12. On the Add Identical Evidence page set Trusted Source to Yes, Share Verifications to Never, and select Relationships evidence.
  13. Click Save and Exit.

Steps to Reproduce (Generic):

  1. Login as a caseworker.
  2. Register a new Person (first person).
  3. Register another new Person (second person).
  4. Click on the Care and Protection tab for the first person and select Cases.
  5. Click on the New page action to create a new case.
  6. Select the integrated case configured for sharing in the Type drop-down and click Save.
  7. Click on the Participants tab and select Case Members.
  8. Use the New page action to add a new member.
  9. Search for the second person in the Name field of the New Member modal and click Save.
  10. On the integrated case click on the Evidence tab.
  11. On the Evidence Dashboard page select the New Evidence page action.
  12. Select All in the Category drop-down to list all evidence types configured on the integrated case. Relationships should be listed.
  13. Use the Add row-level action on the Relationships evidence type to add evidence of that type.
  14. Select the first person in the Case Participant drop-down, second person the Related Participant drop-down, and select a relationship type in the Type drop-down.
  15. Click Save.
  16. Apply changes.
  17. Issue: When examining the Person level evidences to check if the Relationships evidence has been shared, no Relationships evidence is visible. An examination of the server logs shows that a null pointer exception was thrown preventing the completion of the evidence sharing.

Resolution:

Within the Evidence Broker, there is specific logic for handling the sharing of Relationships evidence. It was found that there was an assumption in the logic that the evidence sharing configuration was logically equivalent. The system attempts to look up and process the sharing rules but, as no rules are configured on the system, a null pointer exception is thrown preventing the evidence sharing transaction from completing. The logic has been updated to handle the identical evidence sharing nature of Relationships evidence, thereby resulting in the successful sharing of Relationships evidence in the scenario outlined here.

Known Issues

See the Known Issues section in the 7.0.2.0 release notes.

Notices

Before using this information and the product it supports, read the information in "Notices".

Document Information

More support for:

Merative Social Program Management

Software version:

7.0.4

Operating system(s):

Linux, Windows

Modified date:

09 April 2020