Merative ™ Social Program Management 7.0.4.4

Release Notes

Abstract

Merative Social Program Management 7.0.4.4 Release Notes

Content

IntroductionSystem 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 release.

This is a cumulative release which incorporates the Improvements, Resolved Issues and Third Party Updates contained in all previous 7.0.4 Fix Pack releases. Details of these Improvements, Resolved Issues and Third Party Updates are included separately in the release notes for each of the previous Fix Pack 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 documentation.

A CSV file is attached at the end of this document, which summarizes these release notes.

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/spm

Installation

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

The installation steps are as follows:

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
Cúram Enterprise Framework
Cúram Modules
Solutions

Third Party Updates

WorkItem:250864 - Update the versions of the Jackson JARs to the latest version

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 utilizes these utilities.
The versions of the Jackson JARs have now been updated from 2.4.2 and 2.9.5 to the latest version.
As a result of this upgrade, the following changes have been made in the JDE and REST deliverable.

WorkItem:251879 - Browser Support Update

The following browser versions have been updated and certified for this release:

Case Worker Application Browser Support

Universal Access Application Browser Support

WorkItem:251880 - Update Browser Plugins JRE levels used in Microsoft Word Integration

The following JRE level for Word Integration is supported for this release:

WorkItem:252333 - Tablet Accessibility Support

The certified version of Apple VoiceOver has been updated to iOS 12.4 This has been certified against Chrome 76.

Cúram Enterprise Framework

Integrated Case Management
Intake

Integrated Case Management

Evidence Management

EVIDENCE MANAGEMENT

PO08020, WorkItem:252008 - Update with Incoming wizard throws an error with incorrect evidence date '01/01/0001' shown

Issue Description:

Updating with Incoming correction was incorrectly using the incoming evidence's effective date to verify the integrity of the expected timeline for all evidence in a timeline. However for the first record in a timeline where no effective date is populated, it should instead use the period start date. This resulted in an incorrect validation message occurring using the null effective date in the message.

**User Interface Impact: **No

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Submit an application with a past date (1st May 2018, for example) for a member with an Income of $500/monthly and start date of 1/1/2018.
  4. Authorize the Application Case.
  5. Navigate to the Insurance Affordability integrated case and edit the Income evidence with the following changes:
    • Edit the Effective Date Of Change to 1st March 2018 and the amount to $600 monthly.
    • Edit the Effective Date Of Change to 1st May 2018 and the amount to $700 monthly.
    • Edit the Effective Date Of Change to 1st July 2018 and the amount to $800 monthly.
    • Verify (if required) and Apply Changes.
  6. The Income evidence will have the following set of succession records on the integrated case:
    • 1/1/2018 to 2/28/2018 – $500 monthly.
    • 3/1/2018 to 4/30/2018 – $600 monthly.
    • 5/1/2018 to 6/30/2018 – $700 monthly.
    • 7/1/2018 to ongoing - $800 monthly.
  7. Submit a new application for the same member with an application date of 20th September 2018 and latest income set to $1000 monthly starting on 1st September 2018.
  8. Authorize the new Application Case selecting the existing Insurance Affordability integrated case during the authorization process.
  9. Navigate to the Incoming evidence tab on the Insurance Affordability integrated case.
  10. Expand the Income evidence and compare the timelines of the incoming evidence and the existing evidence.
  11. In the actions menu of the Existing Evidence, select Update with Incoming.
  12. Select the incoming Income evidence in the Update with Incoming wizard and click Next.
  13. Select the Correction option and click Next.
  14. Issue: The system throws an error message with an incorrect evidence date:
    • 'The effective dated incoming values may already exist on this case, please compare against existing evidence on 01/01/0001 and correct existing using incoming values if required.'

Resolution:

The validation has been updated to use either period start date or effective date as appropriate when validating the integrity of the expected timeline. If an effective date exists on the evidence it will be used. If no effective date exists on the evidence, in the scenario of initial record in a succession, the evidence period start date will be used instead. This results in the error message no longer occurring in this scenario and the correction can be performed.

WorkItem:252011 - If no case participant attribute exists within an evidence hierarchy then the incorrect case participant is returned for any evidence of this type

Issue Description:

An issue existed in the generated code for static evidence types whereby a fallback mechanism was not in place for evidence in a hierarchy structure that contained no case participant attribute. That is, the parent, child, grand-child, and so on, did not contain a case participant attribute. This was causing problems for places in the application that required a case participant value in order to complete successfully, as no case participant was being returned in this scenario. For example, verifications at the product delivery level required a case participant and therefore they were not created for any evidence with no case participant attribute in its hierarchy.

For customers using the Income Support product, an example of this is Shelter Expense and Contributor. These are static evidence types with no case participant attribute in this business object, if product delivery verifications were configured against this evidence, no verifications were created.

Note: this issue does not impact dynamic evidence types.

**User Interface Impact: **No

Steps to Reproduce:

  1. Set up a product delivery verification for evidence in a hierarchy structure that has no case participant. The evidence may live at the integrated case level, but the verification requirement should be for the associated product delivery.For Income Support customers, Shelter Expense and Contributor can be used to demonstrate this. Otherwise static evidence types with no case participant attribute in the hierarchy.
  2. Create the necessary cases and add the evidence, parent, child, grand-child etc.
  3. To view the verifications at the product delivery level, a custom page may need to be added to the tab associated with the product. For Income Support customers, PD_evidenceListVerificationsForCase.uim can be used.
  4. When viewing the product delivery, the page for listing the verifications should be visible.
  5. The page should contain the verification that was created for the product delivery, but the issue is that it doesn't.

Resolution:

The evidence generator for static evidence has been updated to provide a fallback mechanism in the above scenario. The functionality now falls back on the case participant role associated with the participant on the evidence descriptor. This ensures the correct case participant is identified. For the example of the verifications scenario where this arose, the configured product delivery verifications are now created as expected.

Intake

PO07757, WorkItem:252010 - When Intake Resilience and Advanced Evidence Sharing are enabled, duplicate evidence records appear on an Insurance Affordability Application Case

Issue Description:

When Intake Resilience and Advanced Evidence Sharing are enabled, duplicate evidence records are shared from the Person Record to an Insurance Affordability Application Case.

**User Interface Impact: **No

Prerequisite(s):

The following system properties should be set:

  1. curam.intake.use.resilience=YES
  2. curam.aes.advancedEvidenceSharingEnabled=YES

A Logically Equivalent evidence sharing rule is configured for Person Record Identifications to Insurance Affordability Application Case SSN Details using the out-of-the-box XML configuration with Trusted Source set to Yes.
Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person and add Identification evidence with the type set to Social Security Number.
  3. Create and submit a new Insurance Affordability Application.
  4. Navigate to the newly created case.
  5. Issue: There are two identical SSN Details evidence records on the case.

Resolution:

This issue has been resolved and duplicate evidence records are no longer shared from the Person Record to an Insurance Affordability Application Case.

Technical:

A new version of the Process Intake Application Workflow has been provided. Previously, the resiliency path through this workflow created the application case and added one or more person(s) to that case. Adding members to a case initiates the Evidence Sharing Pull Workflow before then moving on to mapping evidence from the application script to the case. This causes an issue where the SSN Details gets shared and mapped to the case simultaneously, resulting in the duplication of evidence. The new workflow delays the sharing until later so that it never runs in parallel with the mapping. This has been achieved by nesting a subflow for the Evidence Sharing Pull Workflow within the Process Intake Application Workflow.

Cúram Modules

Intelligent Evidence Gathering
Evidence Broker

Intelligent Evidence Gathering

WorkItem:248281 - Merative Universal Access Responsive Web Application: Mandatory questions that use arrays and check boxes not marked as Required

Issue Description:

Mandatory IEG script questions with array type and check-boxes are not marked as required in the Universal Access Responsive Web Application.

**User Interface Impact: **No

Steps to Reproduce:

  1. Update an IEG script to contain a question with array type and check-boxes and mark that question as mandatory.
  2. In the Universal Access Responsive Web Application, apply for a benefit by using that IEG script.
  3. Observe that the question doesn't display the required indicator next to the label.

Resolution:

Mandatory IEG script questions with array type and check-boxes are now marked as required in the Universal Access Responsive Web Application.

WorkItem:249132 - Merative Universal Access Responsive Web Application: Remove control questions from summary pages

Issue Description:

Control questions that are defined in a loop are shown when accessed from summary pages in the Universal Access Responsive Web Application.
User Interface Impact: No

Steps to Reproduce:

  1. Update an IEG script to contain a loop with a control question where loop pages can be accessed from the summary page using 'Edit' or 'Add' buttons.
  2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
  3. Populate loop pages and observe that control questions are accessed as expected.
  4. Continue up to the summary page and from here access already populated loop pages using 'Edit' button or new loop pages using 'Add' button.
  5. Observe that the control question is displayed.

Resolution:

Control questions that are defined in a loop are now hidden when accessed from summary pages.

WorkItem:250034 - Merative Universal Access Responsive Web Application: IEG pages that contain conditional clusters with read-only expressions are not displayed

Issue Description:

An error message is displayed when trying to access IEG script pages that contain conditional clusters with read-only-expressions.

**User Interface Impact: **No

Steps to Reproduce:

  1. Update an IEG script to contain a conditional cluster with a read-only-expression.
  2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
  3. An error message is displayed: 'Something went wrong. Try again or go to home'.

Resolution:

IEG pages that contain conditional clusters with read-only-expressions are now successfully displayed.

WorkItem:250035 - Merative Universal Access Responsive Web Application: Informational messages missing for IEG clusters and lists

Issue Description:

Informational messages that are defined for a cluster or a list are not displayed.

**User Interface Impact: **No

Steps to Reproduce:

  1. Update an IEG script to contain a cluster and a list with informational messages.
  2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
  3. Observe that informational messages are not displayed for the cluster or list.

Resolution:

Informational messages that are defined for a cluster or a list are now displayed as expected.

WorkItem:250180 - Merative Universal Access Responsive Web Application: Issues with Read-only Conditional Fields

Issue Description:

An editable question that is defined in a conditional visible cluster is displayed as read-only.

User Interface Impact: No

Steps to Reproduce:

  1. Update an IEG script to contain two dynamically conditional clusters where the first cluster does not meet the condition and is hidden and the second cluster meets the condition and is visible.
  2. Add the same question to both clusters. Add the question to the first cluster as read-only, and add the question to the second cluster as editable.
  3. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
  4. Observe that the editable question that was defined in the second cluster is displayed as read-only.

Resolution:

An editable question that is defined in a conditional visible cluster is now editable as expected.

WorkItem:251527 - Merative Universal Access Responsive Web Application: Mandatory questions that use arrays and check boxes do not show the client-side validation messages

Issue Description:

Mandatory IEG script questions with array type and check boxes do not show mandatory client-side field-level validation messages in the Universal Access Responsive Web Application.

User Interface Impact: No

Steps to Reproduce:

  1. Update an IEG script to contain a question with array type and check boxes and mark that question as mandatory.
  2. In the Universal Access Responsive Web Application, apply for a benefit by using that IEG script.
  3. Progress to the page containing the check box question, do not select anything, and click 'Continue.
  4. Observe that the mandatory client-side field-level validation message is not displayed. The mandatory server-side validation message at the top of the page is displayed.

Resolution:

Mandatory questions in IEG scripts with array type and check boxes now show client-side field-level mandatory validation messages.

Evidence Broker

PO07891, WorkItem:251992 - Incoming Evidence page does not display correct dates when a user's timezone is not Coordinated Universal Time (UTC)

Issue Description:

The Incoming Evidence page is not displaying the correct dates in the Incoming Evidence or Existing Evidence timelines when a user's timezone is set to a different timezone other than Coordinated Universal Time (UTC). This causes the 'Update with Incoming' evidence modal and 'Set as Latest of Incoming' evidence modal to not correctly display incoming evidence due to the incorrect dates being used in the timelines.

**User Interface Impact: **Yes

Steps to Reproduce:

The issue occurs on the Incoming Evidence screen for all cases. The steps below require prerequisite setup in Admin; login to Admin and create an Integrated Case called Social Assistance and add email evidence to this case.

  1. Change the client machine's timezone to EST, e.g. New York.
  2. In Admin; check to ensure there is no identical sharing configuration setup for Social Assistance - Email > Social Assistance - Email.
  3. Register a person.
  4. Create a Social Assistance case for that person (Case 1).
  5. Add email evidence with a start date of yesterday & apply changes.
  6. Create another Social Assistance case for that person (Case 2).
  7. Login to Admin and now add identical sharing configuration of Social Assistance - Email > Social Assistance - Email.
  8. Login as caseworker again and add email evidence to Case 2 with a start date of today & apply changes. This will trigger Advanced Evidence Sharing (AES) but as the two Email evidences can't be reconciled it will be added to the Incoming Evidence list.
  9. Open the Incoming Evidence page on Case 1 and toggle the Email evidence inline page. The start date on both the incoming and the existing evidence will be correct, but the dates shown in the timeline will be a day earlier.
  10. Selecting 'Update with Incoming' or 'Set as Latest of Incoming' from the existing Email's actions will display a modal with an empty evidence list.

Resolution:

The Incoming Evidence page will now take the browser's timezone into account and display the correct dates on the Incoming Evidence and Existing Evidence timelines.Technical:

The issue was addressed by updating the following file

to include a _getDate(dateString) function which formats dates in the browser's timezone.

PO08415, WorkItem:251996 - Validation issue when trying to upload logically equivalent XML for evidence sharing

Issue Description:

When configuring evidence sharing, it's not possible to upload logically equivalent XML which contains a 'Set' action with more than one parameter specified. These parameters are used for defaulting values on the target entity during logically equivalent sharing, which can arise when the data isn't available from the source evidence. At least one parameter must be specified in the 'Set' action, and the schema to which the XML adheres, and which it's validated against, should allow for multiple parameters, not just one.

**User Interface Impact: **No

Steps to Reproduce:

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure Logically Equivalent sharing between two evidence types on two case types.
  4. Now browse and select a sharing XML file that contains a Set action with more than one parameter specified.
  5. Click Save & Exit.
  6. Issue: An exception is thrown and it's not possible to save the configuration.

Resolution:

This issue has been resolved and it's now possible to complete the configuration for logically equivalent sharing when there is more than one parameter specified for a Set action.

Technical:

The underlying problem was that maxOccurs was not specified for the parameter element for Set within the logically equivalent XML, and this defaults to 1. The issue has been addressed by including maxOccurs on the parameter element and setting it to 'unbounded'.

PO08223, WorkItem:251997 - Income shares incorrectly from an Insurance Affordability integrated case to an Income Support integrated case despite the system determining that the evidence should not share

Issue Description:

When the following logically equivalent sharing configurations exist for sharing Income on an Insurance Affordability integrated case to evidence types on an Income Support integrated case

and the system determines that only the Paid Employment > Earned Income business object should be created on the target, in line with the ShareWhen rule, Benefit and Unearned Income are also appearing on the Incoming Evidence screen, despite the system initially determining that these should be ignored as the sharing rules for both types fail.

**User Interface Impact: **No

Prerequisite(s):

  1. Login as a system administrator.
  2. Click on Property Administration under Application Data in the shortcuts panel.
  3. Search for a property with the name 'Advanced Evidence Sharing' and ensure its value is set to YES.
  4. Login as an administrator.
  5. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  6. 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 = No.
    • Browse and upload the correct XML sharing file.
    • Click Save & Exit.
  7. Repeat step 3 for the other evidence mappings, uploading the appropriate XML sharing file for each one:
    • Income > Earned Income
    • Income > Benefit
    • Income > Unearned Income

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create a new Insurance Affordability application for the Person. Don't add any income as part of the application.
  4. Authorise the application. This will create an Insurance Affordability integrated case.
  5. Login as an Income Support caseworker.
  6. Search for the Person created above.
  7. Click on the Care and Protection tab.
  8. Use the New Case page action to create an Income Support integrated case.
  9. Login as an Insurance Affordability caseworker.
  10. Go to the Insurance Affordability integrated case and create Income evidence. Add Income of type Wages and Salaries.
  11. Activate the evidence.
  12. Login as an Income Support caseworker and navigate to the Income Support integrated case.
  13. Navigate to Incoming Evidence under the Evidence tab.
  14. Issue: There is incoming evidence for Paid Employment > Earned Income, Benefit and Unearned Income when there should only be Paid Employment > Earned Income for the Wages and Salaries mapping. Wages and Salaries is not included in the ShareWhen mapping criteria for the Benefit or Unearned Income. evidence types.

Resolution:

This issue has been resolved and now when the above scenario is run, only Paid Employment > Earned Income is shared to the target case.
Technical:

The underlying problem here was that even though the system determined that sharing between Income and Benefit and Income and Unearned Income should have been ignored, as the sharing XML returned false from the ShareWhen clause, the delivery of the Paid Employment evidence threw an exception as some of the mandatory fields were not available. This forced the sharing to go down the resilience path. In this instance, the system action for Income to Benefit and Income to Unearned Income was updated to Caseworker Review. This is why these appeared in the Incoming Evidence screen.

The logic has been updated to not overwrite a system action of ignore when resilience is hit as part of evidence sharing. This means that in the above scenario, that neither Benefit nor Unearned Income will appear in the Incoming Evidence screen on the Income Support integrated case.

PO08413, WorkItem:251998 - Logically equivalent evidence updates between Insurance Affordability and Income Support integrated cases are being shared back and forth endlessly

Issue Description:

Logically equivalent evidence is being shared back and forth endlessly between an Insurance Affordability integrated case and an Income Support integrated case.

**User Interface Impact: **No

Related WorkItem(s): 250212

Prerequisite(s):

  1. Login as system administrator and click on Property Administration under Application Data in the shortcuts panel.
  2. Search for a property with the name 'Advanced Evidence Sharing' and ensure its value is set to YES.
  3. Now navigate to Code Tables under Application Data in the shortcuts panel.
  4. Search for the LivingArrangementType code (default value is Home).
  5. Use the New Item row level action to create a new code-table entry with the values:
    • Item Name set to Incarceration.
    • Technical ID (Code) set to LA10000, for example.
    • Click Save.
  6. Publish the changes.
  7. Login as an administrator and navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  8. Configure a new evidence sharing configuration with the following details:
    • Select Income Support as the source and Insurance Affordability 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 Living Arrangement as the source evidence type and Incarceration as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the correct XML sharing file, the key aspect being the ShareWhen which determines that sharing should occur when the Living Arrangement Type is set to Incarceration. There is also a Set action for creating Incarceration evidence on the target with default values specified for Charge Status (Convicted) and Incarceration Status (Incarcerated).
    • Click Save and Exit.
  9. Create a second 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 Incarceration as the source evidence type and Living Arrangement as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the correct XML sharing file, the key aspect being a Set action which determines the creation of Living Arrangement evidence on the target with a default value specified for the Living Arrangement Type (Incarceration). There is also a maintenance style set on the XML of ENDDATE.
    • Click Save and Exit.

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a new Person.
  3. Create a Medical Assistance application for this Person, specifying the Living Arrangement to Home.
  4. Submit the application and check eligibility.
  5. Clear verifications and authorise the product delivery.
  6. Activate the product delivery.
  7. Login as Insurance Affordability caseworker and create an application for the same Person.
  8. Authorise the application; this results in an Insurance Affordability integrated case being created.
  9. Login as an Income Support caseworker.
  10. End date the existing living arrangement using yesterday's date and add a new living arrangement starting the following day (today) of type Incarceration.
  11. Activate the evidence.
  12. Login as an Insurance Affordability caseworker.
  13. Navigate to Incoming Evidence under the Evidence tab on the Insurance Affordability integrated case.
  14. For the Incarceration evidence, select Add to Case. Once added to the case, activate the evidence.
  15. Login as an eligibility worker and navigate to the Incoming Evidence on the Income Support integrated case.
  16. Issue: The Incarceration evidence appears on the Income Evidence screen.

Resolution:

This issue has been resolved. Now when the Incarceration evidence is added to the Insurance Affordability case and activated, the evidence is not shared back to the Income Support integrated case.

Technical:

There were two issues that needed to be addressed when fixing this issue:

  1. The first was a defect in the schema (AESXMLSchema.xsd) which prevented the uploading of the logically equivalent XML file for the sharing configuration of Living Arrangement to Incarceration. This is covered in the Related WorkItem referenced above.
  2. The second was the fact that even though the system links the evidence when it's first shared, on subsequent sharing Ignore (Linked) is initially determined to be the system action but this is effectively discarded because the sharing is logically equivalent. The system then behaves like this is the first time the evidence is being shared.

To address the second point above, a further sanity check is performed to determine if the target entity has the same default values that are specified in Set action in the logically equivalent XML. If they are, then the Ignore (Linked) system action is persisted and no sharing will occur.

PO08368, WorkItem:252002 - Unhandled server exception occurs on Income Support case when activating Pregnancy and Unborn Child evidence which was shared from Insurance Affordability case and added from the Incoming Evidence list page

Issue Description:

When logically equivalent sharing occurs between Pregnancy on an Insurance Affordability integrated case to Pregnancy > Unborn Child on an Income Support integrated case, an unhandled server exception is encountered when activating the evidence after adding it from the Incoming Evidence screen.

**User Interface Impact: **No

Prerequisities

  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 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 Pregnancy as the source evidence type and Pregnancy as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the correct XML sharing file.
    • Click Save and Exit.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create a new Insurance Affordability application case for the Person. Don't specify any income.
  4. Authorise the application case; an Insurance Affordability integrated case is created.
  5. Login as an Income Support caseworker.
  6. Submit an Income Support application for the Person registered above, for Medical Assistance with no income, but with benefit type Medicare Part A.
  7. Check eligibility and activate the evidence.
  8. Authorise the application.
  9. Add Pregnancy evidence on the Insurance Affordability integrated case and activate it.
  10. Navigate to the Income Support integrated case and add the incoming Pregnancy > Unborn Child evidence.
  11. Activate the evidence on the Income Support integrated case, making sure to select Pregnancy and Unborn Child.
  12. Issue: An unhandled exception is encountered when activating the evidence.

Resolution:

This issue has been resolved and it's now possible to activate Pregnancy and Unborn Child evidences on an Income Support case after they have been added to the case through from the Incoming Evidence screen.

Technical:

This problem here was caused by the Create action in the XML mapping between Pregnancy on Insurance Affordability and Pregnancy on Income Support. The Create action was incorrectly adding the Unborn Child evidence directly to the case even when Trusted Source was set to No. This creates a relationship between the incoming Pregnancy evidence and the Unborn Child evidence on the in-edit screen. When the Pregnancy record is added to the case it gets a new Evidence Descriptor. As the Unborn Child is already on the case and associated with an Evidence Descriptor that is not active or in-edit, it is effectively orphaned and neither the Unborn Child nor the Pregnancy can be activated.

To overcome this issue, the logic has been updated so that the Unborn Child evidence is given the same system action as its parent, Pregnancy, if that system action was CASEWORKER_REVIEW or MANUAL_INTERVENTION. With this fix in place, it is now possible to add both the Pregnancy and Unborn Child from the Incoming Evidence screen, and to activate them successfully.

PO08191, WorkItem:252003 - Received Date from an incoming evidence record is not retained following an 'Update with Incoming' action on an existing evidence record

Issue Description:

When the 'Update with Incoming' action is selected on an existing evidence record in the Incoming Evidence list, the Received Date is not taken from the incoming evidence record, instead the Received Date is taken from the existing evidence.

**User Interface Impact: **No

Steps to Reproduce:

Prerequisite(s):

  1. Ensure that the Addresses evidence type is configured against the Integrated Case type used in the scenario below.

Scenario:

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure a New Sharing Configuration for Addresses between the Person Record and any Integrated Case with Trusted Source set to Yes.
  4. Login as a caseworker.
  5. Register a new Person.
  6. Create an Integrated Case for the Person; The Addresses evidence is automatically shared and activated.
  7. Login as an administrator.
  8. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  9. Update the configuration created above and set the Trusted Source to No.
  10. Login as a caseworker.
  11. Search for the Person registered above and navigate to the Person home page.
  12. From the Evidence tab, modify their existing Addresses evidence setting the Received Date to a date in the past and click Save.
  13. On the Integrated Case, navigate to the Evidence tab, then click on Incoming Evidence.
  14. On the Existing Evidence side of the page, click on the 'Update with Incoming' action for the shared Addresses evidence.
  15. Issue: The modify modal does not display the Received Date entered at step 12 above.

Resolution:

This issue has been resolved and the Received Date is now taken from the incoming evidence record for the 'Update with Incoming' step rather than from the existing evidence record.

PO08083, WorkItem:252004 - Unable to add Identifications evidence to a Person from the Incoming Evidence screen

Issue Description:

Logically Equivalent is the process of mapping evidence from one case to another when the evidences are modelled differently on each case. The conditions under which the data is equivalent can vary over time, meaning equivalence across cases may not apply for the full duration of the timeline of evidence. When Trusted Source was set to No, sharing this evidence resulted in sharing all of the timeline of this evidence, incorrectly including the elements that are not logically equivalent. Attempting to action the evidence on the target case resulted in validations as the data was not suitable for the target case.

This is a generic issue for any logically equivalent evidence that can change over time, where conditions of equivalence can vary over this timeline. It is best explained via an example which exists between SSN Details from Insurance Affordability integrated case to Identifications at a Person level. In this example, these are only equivalent when the SSN value is populated. At Person level Identification evidence must have a value populated whereas Insurance Affordability integrated case supports capture of SSN Details without a value. SSN Details without a value indicates that the person has applied for SSN but has not yet received one. During this time, Identifications and SSN Details evidence are not equivalent and therefore it should not be shared to Person level.

With Trusted Source set to No, when sharing a succession of Logically Equivalent evidence where some records in the succession set fail the logically equivalent 'share when' rule, the entire succession set would still get shared to the target case. These records could not be actioned on the target case as the data was not correct/valid there.

**User Interface Impact: **No

Prerequisite(s):

A Logically Equivalent evidence sharing rule is configured for the Insurance Affordability integrated case SSN Details to Person Record Identifications using the out-of-the-box XML configuration with Trusted Source set to No.

Steps to Reproduce (Insurance Affordability specific example):

  1. Login as an Insurance Affordability caseworker.
  2. Create a back-dated Insurance Affordability application, with an application date of two months ago, say, where the Person has no SSN, but 'Applied for SSN' is set to Yes.
  3. Authorise the application.
  4. Navigate to the Insurance Affordability integrated case.
  5. Edit the SSN Details to add an SSN Number and an Effective Date of today and unset 'Applied for SSN' so that it is blank.
  6. Apply changes.
  7. Navigate to the Incoming Evidence screen on the Person.
  8. Expand the SSN Details toggle.
  9. Select 'Add to Case' from the action menu on the incoming evidence on the left side of the screen.
  10. Click Yes on the confirm screen and click Save on the evidence screen.
  11. Issue: The evidence does not get added to the case and a validation is thrown indicating that mandatory fields are not set.

Resolution:

The logic has been updated to prevent records being shared when the logically equivalent 'share when' rule evaluates to false.

Technical

Included as standard in evidence sharing is when evidence is shared with the Incoming Evidence list for caseworker review, the entire business object is kept together in order to provide context on the target case. Certain system actions are reconciled at the business object level to achieve this. For example, if the first part of a succession receives an IGNORE_LINKED action and the second part of the succession receives a CASEWORKER_REVIEW action, the entire business object will be updated to set everything to CASEWORKER_REVIEW.

In this logically equivalent scenario, the same logic applied. The first record in the succession failed the XML 'share when' rule, so it got an action of IGNORE_EXPRESSION_RETURNED_FALSE which prevents that record from sharing. The second record in the succession of the SSN Details record got an action of CASEWORKER_REVIEW because Trusted Source is set to No. Since part of the business object has an action of CASEWORKER_REVIEW, the entire business object is updated to have that action. This causes the first part of the evidence succession to share even though it originally received the IGNORE_EXPRESSION_RETURNED_FALSE action. This record cannot be added to the target case from the Incoming Evidence screen as mandatory data is missing, because it was shared incorrectly.

With the updated logic, IGNORE_EXPRESSION_RETURNED_FALSE will never be overwritten by another action, which will prevent incomplete pieces of evidence being shared to a target case.

PO07984, WorkItem:252005 - Selecting the 'Set as Latest of Incoming' action does not prevent the existing evidence being set as historic evidence

Issue Description:

When choosing the New Version option as the 'Set as Latest of Incoming' action from the existing evidence actions menu, no validations are thrown when the specified Effective Date overlaps with the Incoming Evidence timeline. This means that it's possible to set the existing evidence as something other than the latest in the timeline.

**User Interface Impact: **No

Steps to Reproduce:

  1. From Evidence Sharing under Rules and Evidence in the shortcuts panel, configure evidence sharing between an application case and its associated integrated case, with Trusted Source set to Yes.
  2. Login as a caseworker.
  3. Register a new Person.
  4. Create a new application for the Person.
  5. Add one of the evidence types that was configured for sharing, Income, for example. Make sure the amount is set to $300 and the start date is set to 1/1/2018.
  6. Authorise the application - this should result in an integrated case being created and the Income evidence being shared.
  7. On the integrated case, update the shared Income evidence with an Effective Date of 3/1/2018 and an amount of $500 and apply changes.
  8. Again on the integrated case, update the Income evidence with an Effective Date of 5/1/2018 and an amount of $700 and apply changes.
  9. Create another application case for the Person and add Income evidence with an amount of $1000 and a start date of 7/1/2018.
  10. Now go to the Evidence tab on the application case and click on Incoming Evidence.
  11. Expand the Income evidence.
  12. Select 'Set as Latest of Incoming' from the actions menu on the Existing Evidence side.
  13. Select the Income evidence in the modal and click Next.
  14. Select New Version and specify an Effective Date of 2/1/2018 and click Next.
  15. Issue 1: The Effective Date is not validated and the final modal screen is displayed.
  16. Click Save.
  17. Issue 2: No validations are thrown and the newly created timeline on the case is invalid.

Resolution:

A new validation has been added to the 'Set as Latest of Incoming' wizard on the 'Specify an Action' page to prevent the user from specifying an Effective Date that will result in the evidence being marked as historical in the timeline. That is, it ensures that the existing evidence becomes the latest in the timeline. The same validation is also present on the Edit Income modal at the end of the 'Set as Latest of Incoming' wizard.

PO07981, WorkItem:252007 - Selecting the ’Set as Latest of Incoming' action, ‘Correction’ option does not correctly validate the effective date as latest on the timeline

Issue Description:

When choosing Correction as the 'Set as Latest of Incoming' action from the existing evidence actions menu, no validations are thrown when the specified Effective Date overlaps with the Incoming Evidence timeline. This means that it's possible to set the existing evidence as something other than the latest in the timeline.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an administrator.
  2. From Evidence Sharing under Rules and Evidence in the shortcuts panel, configure evidence sharing between an application case and its associated integrated case, with Trusted Source set to Yes.
  3. Login as a caseworker.
  4. Register a new Person.
  5. Create a new application for the Person.
  6. Add one of the evidence types that was configured for sharing, Income, for example. Make sure the amount is set to $300 and the start date is set to 1/1/2018.
  7. Authorise the application - this should result in an integrated case being created and the Income evidence being shared.
  8. On the integrated case, update the shared Income evidence with an Effective Date of 3/1/2018 and an amount of $500 and apply changes.
  9. Again on the integrated case, update the Income evidence with an Effective Date of 5/1/2018 and an amount of $700 and apply changes.
  10. Create another application case for the Person and add Income evidence with an amount of $1000 and a start date of 7/1/2018.
  11. Now go to the Evidence tab on the application case and click on Incoming Evidence.
  12. Expand the Income evidence.
  13. Select 'Set as Latest of Incoming' from the actions menu on the Existing Evidence side.
  14. Select the Income evidence in the modal and click Next.
  15. Select Correction and click Next.
  16. Update the Effective Date to 1/1/2018.
  17. Click Save.
  18. Issue: No validations are thrown and the existing evidence is not retained as the latest evidence in the timeline.

Resolution:

A new validation has been added to the final Edit modal in the 'Set as Latest of Incoming' wizard which prevents the user from entering an Effective Date that will result in the evidence being marked as historical in the timeline. That is, it ensures that the existing evidence becomes the latest in the timeline.

WorkItem:252009 - Update with Incoming wizard does not allow a correction to be performed if the incoming evidence start date is already on the existing evidence timeline

Issue Description:

For evidence sharing the 'Update with Incoming' correction flow does not allow a correction to be performed when the incoming record evidence period start date already exists on the current timeline. The validation exists to preserve the integrity of the current timeline but it is incorrectly preventing this scenario as it is valid the start date can already exist on the timeline when performing a correction.
**User Interface Impact: **No

Prerequisite(s):

An application case is configured to create an integrated case when authorised. An evidence type that supports effective dating is configured on both the application case and integrated case and is enabled for sharing. A sharing configuration exists from the application case to the integrated case for the evidence with Trusted Source set to Yes.Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Create an application case for the Person.
  4. Navigate to the application case and create the configured evidence with a start date of 3/3/2019.
  5. Authorise the application.
  6. Create another application case for the Person.
  7. Navigate to the new application case and create the configured evidence with a start date of 1/1/2019.
  8. Edit the newly created evidence and add an Effective Date of 2/2/2019.
  9. Edit the same evidence again and add an Effective Date of 3/3/2019.
  10. Navigate to the Incoming Evidence screen.
  11. Expand the configured evidence.
  12. Select 'Update with Incoming' from the actions menu on the Existing Evidence side.
  13. Select the configured evidence in the modal and click Next.
  14. Select Correction and click Next.
  15. Issue: A validation is thrown stating that the incoming evidence record start date already exists in the existing evidence succession.

Resolution:

This validation has been updated to first check the evidence period start dates of the two pieces of evidence being corrected. If the incoming record evidence period start date matches the evidence period start date of the existing record that is being corrected, a validation is no longer thrown and the correction can be performed.

WorkItem:252065 - On the Incoming Evidence screen, it is not possible to remove a business object if part of the object has no action available

Issue Description:

When sharing evidence, it is not possible to remove a business object from the Incoming Evidence screen if part of the object has no action available because it is identical to what is already on the 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 No between two case types, A and B, that have Student and Student Expense evidence associated with them.
  4. Click Save and Exit.

Steps to Reproduce:

Share the first time:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Create an instance of case A for the Person.
  4. Create an instance of case B for the Person.
  5. Add Student and Student Expense evidence to case A.
  6. Activate the evidence.
  7. Navigate to the Incoming Evidence screen of case B.
  8. For both the Student and Student Expense, select Add To Case.
  9. Activate the evidence.

Share the second time:

  1. On case A, add a new Student Expense record and associate it with the existing Student evidence.
  2. Activate the evidence.
  3. Navigate to the Incoming Evidence screen of case B.
  4. Action the Student Expense records.
  5. Issue: The actions are greyed out on the Student parent evidence, which means it is identical to the Student evidence already on the target case. After resolving the Student Expense records, it is not possible to remove the business object from the Incoming Evidence screen as the status of the Student record is 'Identical Shared In-Edit'.

Resolution:

This issue has been resolved and it is now possible to remove a business object when a part of the object has no actions available because it is identical to what is present on the target case.

Technical:

When presenting evidence on the Incoming Evidence list, a check is performed to see if the Incoming Evidence is identical to what is already on the target case. If it is identical, then the actions are greyed out on the incoming record. As part of this check, the status of the Incoming Evidence record is also changed from 'Identical Shared In-Edit' to 'Identical Shared Discarded'. This results in a caseworker being able to remove the business object when the other elements of the business object have been resolved.

WorkItem:252066 - Income Support Earned Income types other than those configured to share to Insurance Affordability Income are appearing as in-edit on the target case

Issue Description:

For the logically equivalent sharing of Income Support Earned Income to Insurance Affordability Income, Earned Income types other than the one configured for sharing, which is Wages and Salaries, are being shared to the target case as In-Edit with a blank Income Type.

**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 Insurance Affordability 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 Earned Income as the source evidence type and Income as the target evidence type.
    • Share Verifications = Never, Trusted Source = Yes.
    • Browse and upload the sample XML file from DeveloperWorks (CGISSEarnedIncome_HCRIncome.xml). This file maps income type of 'Wages and Salaries' only.
    • Click Save and Exit.

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a new Person.
  3. Create a new Employment record for the person, with a start date in the past.
  4. Select the Care and Protection tab and click on the New page action.
  5. Create a new Income Support integrated case for the Person and add the following evidence:
    • Household Member
    • Head of Household
    • Living Arrangement
  6. Add Paid Employment evidence to the case to reflect the person's employment.
  7. Add Earned Income of type Bonus and associate it with the Paid Employment.
  8. Activate the evidence.
  9. Login as an Insurance Affordability caseworker.
  10. Search for the Person created above.
  11. Select the Care and Protection tab and click on the New page action.
  12. Create a new Insurance Affordability integrated case for the Person.
  13. Issue: In-Edit Income evidence with a blank Income Type exists on the Insurance Affordability integrated case. This evidence should not have been shared as the sharing rules are only configured to share Earned Income of type Wages and Salaries.

Resolution:

This issue has been resolved and now Earned Income on an Income Support integrated case will only be shared to Income on Insurance Affordability integrated case when the income type is Wages and Salaries, and when the sample XML configuration referenced above is used.

Technical:

The underlying problem here is that there were two Evidence Mapping configurations specified in the logically equivalent XML, one for the parent evidence of Paid Employment and one for the child evidence of Earned Income. When processing this XML configuration, the system determined that there were two sharing rules, again one per evidence type, parent and child. However, the system could not determine categorically which sharing rule applied to which evidence type as the processing matched on the target evidence type and not on source evidence type.

Solutions

Income Support
Common Evidence

Income Support

Medical Assistance

MEDICAL ASSISTANCE

WorkItem:250223 - APIs to support HCR Change of Circumstance (CoC) processing on an Merative Universal Access Responsive Web Application

Merative Social Program Management Health Care Reform (HCR) includes Change of Circumstance (CoC) processing that allows the citizen to create and submit a CoC application through the Merative Universal Access Application citizen portal.

To support the ability to implement HCR CoC processing on the Merative Universal Access Responsive Web Application, the following APIs are now available for use.

The APIs enable the key business functions that form part of the Merative Social Program Management Health Care Reform (HCR) Change of Circumstance (CoC) processing, including the ability for a citizen to view their existing information and initiate an update to the information.

Note that the APIs do not cover the entire set of use cases that may be required to fully implement HCR CoC processing on the Merative Universal Access Responsive Web Application.

The following four APIs are available for use:
GET /hcr/information_summary
Returns a summary of personal and household information for the applicant, and whether they have other change of circumstances, life events, or health plan renewals in progress.

POST /hcr/change_of_circumstance_form
Starts a change of circumstance form.

POST /hcr/change_of_circumstance_form/motivation
Creates a motivation and runs the corresponding eligibility determination, based on the answers that are provided in the change of circumstance form.

POST /hcr/change_of_circumstance_form/sign_and_submit
Creates an e-signature for the change of circumstance form and submits the form to the agency.

For full specification details for the four new HCR Change of Circumstance (CoC) APIs, please see the Social Program Management Swagger specification, which is available from a running Social Program Management instance at http://<hostname>:<port>/Rest/api/definitions/v1.

PO07710, WorkItem:252012 - Address Evidence Preferred indicator not set on the integrated case and application case

Issue Description:

When an Insurance Affordability application was submitted, the preferred address attribute was not set correctly in 'Private Address' evidence.

**User Interface Impact: **No

Steps to Reproduce:

  1. Login as Insurance Affordability caseworker.
  2. Register a participant and enter the address in Private Address cluster.
  3. Submit an application for the registered person selecting 'Yes' for both of the following questions on the 'Information About You' page -
    • Do you have a fixed address?, and
    • Is the mailing address the same as home address?
  4. Authorise the application. The integrated case is created successfully.
  5. Navigate to the integrated case and select Evidence > Dashboard > Addresses and verify the private address.
  6. Issue: In “Address Details” section the Preferred indicator value is "No".

Resolution:

The preferred address attribute wasn't set during the evidence mapping. The preferred address attribute is now set correctly.

Common Evidence

PO08439, WorkItem:252000 - Evidence cannot be added to a case via the Incoming Evidence screen if it contains a related case participant role field

Issue Description:

A validation occurs stating that a participant is not set when trying to add evidence to a case from the Incoming Evidence list page, where the evidence contains related participants.
**User Interface Impact: **No

Prerequisite(s):

  1. Login as a system administrator.
  2. Click on Property Administration under Application Data in the shortcuts panel.
  3. Search for a property with the name 'Advanced Evidence Sharing' and ensure its value is set to YES.

The following logically equivalent sharing rules should be configured for an Insurance Affordability integrated case to an Income Support integrated case using the sample XML configurations from Merative DeveloperWorks with Trusted Source set to No.

  1. Income to Paid Employment.
  2. Income to Earned Income.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an application with a monthly Income of type Wages and Salaries.
  4. Authorize the application.
  5. Login as an Income Support caseworker.
  6. Create an Employment participant for the Person.
  7. Create an Income Support integrated case.
  8. Navigate to the Incoming Evidence screen for the Income Support integrated case.
  9. Expand the incoming evidence record.
  10. Click Actions on the Paid Employment evidence and select Add to Case.
  11. Click OK.
  12. Select the Employment record and click Next.
  13. Click Finish.
  14. Issue: A validation is thrown stating that the participant must be selected.

Resolution:

This issue has been resolved by correctly setting participants on evidence when using the Add to Case function on the Incoming Evidence screen.

Technical:

Code for handling related participants on certain evidence types was missing in the static evidence generator style-sheet(s). This caused the related participant identifier not to be set, which resulted in a validation preventing the evidence from being added to the case. The generator style-sheet(s) have been updated to include the necessary related participant logic in the Add to Case function. This means a caseworker is now able to successfully add such evidence to a case via the Incoming Evidence screen.

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".

CSV Release Notes

ReleaseNotes_7.0.4.4.csv

This CSV file summarizes the individual release notes documented above in the "Improvements, Resolved Issues and Third Party Updates" section. The individual release notes documented above will be maintained and will reflect the latest version of the release notes from eGA onwards. However, the content of this CSV file is valid on eGA date, but is not maintained after that.

Document Information

More support for:

Merative Social Program Management

Software version:

7.0.4

Operating system(s):

Linux, Windows

Modified date:

19 September 2019