7.0.5.0 release notes

Release Notes

Abstract

Merative Social Program Management 7.0.5.0 Release Notes

Content

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

Introduction

Welcome to the Merative Social Program Management 7.0.5.0 release. Read this document to find important installation information, and to learn about product improvements and resolved issues in this release.

For information about what's new in version 7.0.5.0, see the What's new in Version 7.0.5.0 topic in the product documentation.

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

For the latest version of the release notes, see https://curam-spm-devops.github.io/wh-support-docs/spm/release-notes.

A CSV file is attached at the end of this document, which summarizes these release notes. Also attached are PDFs providing more details of Code Removals in this release.

This 7.0.5.0 release incorporates content from previous 7.0.X releases, which is documented separately in the following sets of online release notes:

Note: features that were disabled by default in 7.0.X refresh packs will be enabled by default in this release.

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

Install the Merative software and supported related software according to the Installing Merative Social Program Management instructions in the Documentation.

Ensure that you install the Merative Social Program Management Platform, application modules and program-based offerings in the correct sequence as described in the Overview of the installation steps topic.

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/curam.

Improvements, Resolved Issues, Third Party Updates and Code Removals

Third Party Updates

WorkItem:230408 - Browser Support Update

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

Case Worker Application Browser Support

Google Chrome updated to 70
Microsoft Edge updated to 44

Universal Access Application Browser Support

Google Chrome updated to 70
Mozilla Firefox updated to 63
Apple Safari updated to 12
Microsoft Edge updated to 44

WorkItem:230409 - Introduce support for JAWS 2018 and Internet Explorer 11

The version of JAWS used by the application has been updated to JAWS 2018. This new version of JAWS has been certified against Internet Explorer 11.

WorkItem:230411 - Tablet Accessibility Support - Certify Apple VoiceOver with Chrome 70 on iOS 12.0.1

The certified version of Apple VoiceOver has been updated to iOS 12.0.1. This has been certified against Chrome 70.

WorkItem:230412 - Upgrade Adobe Flash Player to the latest version

The version of the Adobe Flash Player that has been certified to be used by the Social Program Management (SPM) application has been updated to 31.

WorkItem:233765 - Introduce the XML Unit Core library into the product

XMLUnit provides helper classes to validate generated XML against an XML Schema, assert the values of XPath queries or compare XML documents against expected outcomes.

It provides a diff-engine which provides full control over what kind of difference is required and which part of the generated document to compare against reference documents.

Version 2.6.0 of the XML Unit Core library has now been introduced into the SPM product. The library is located in the CuramSDEJ/lib directory.

WorkItem:236407 - Update the version of Apache FOP used in the Social Program Management application

Apache™ FOP is a print formatter driven by XSL formatting objects and an output independent formatter. It is used by the Merative SPM XML Server in the generation of PDF documents.

The version of FOP used by the Merative SPM XML Server has now been updated from 2.2 to 2.3. FOP 2.3 contains some bug fixes and a number of improvements.

As a result of this upgrade, the following changes have been made in the Java Development Environment deliverable.

CuramSDEJ\lib\third_party_version.properties - the versions of the specified FOP related JARs have been updated.
CuramSDEJ\xmlserver\third_party_version.properties - the version of the specified FOP related JARs have been updated.

The existing avalon-framework.jar file present in previous versions of the FOP deliverable has now been split into two separate JAR files. As a result of this, the following changes have been made.

CuramSDEJ\xmlserver\avalon-framework-4.2.0.jar - this JAR file has been removed.
CuramSDEJ\xmlserver\avalon-framework-api-4.3.1.jar - this JAR file has been added.
CuramSDEJ\xmlserver\avalon-framework-impl-4.3.1.jar - this JAR file has been added.

The changes to the other FOP related JAR files include:

CuramSDEJ\xmlserver\batik-all-1.10.jar - new version of the batik-all JAR.
CuramSDEJ\xmlserver\fop-2.3.jar - new version of the FOP JAR.
CuramSDEJ\xmlserver\xmlgraphics-commons-2.3.jar - new version of the xmlgraphics-commons JAR.
CuramSDEJ\xmlserver\xml-apis-ext-1.3.04.jar - this JAR file has been added.

It should be noted that any references in custom scripts and other artifacts to the now removed "CuramSDEJ\xmlserver\avalon-framework-4.2.0.jar" should be updated to point to the two newly added avalon JARs as described above.

WorkItem:236723 - Introduce the jsoup library into the product

Jsoup provides helper classes to cleanse HTML documents and strings of malicious code.

Version 1.11.3 has been introduced into the product to improve security. The library is located in the CDEJ/lib/ext/jar directory.

Cúram Enterprise Framework

Dynamic Evidence

PO06625, WorkItem:174836 - Prevent a case worker from effective dating an evidence before the business start date of an evidence

Issue Description:

The dynamic evidence infrastructure currently allows a caseworker to create a succession where the effective date is earlier than the business start date of the evidence being updated.

User Interface Impact: No

Steps to Reproduce:

Login as Admin
Create a new dynamic evidence type called Earnings
Associate this dynamic evidence type with an Integrated Case
Login as Caseworker
Register a person.
Create an Integrated Case of the type used in Admin for Earnings evidence
Create an Earning evidence. (Current date)
Activate the Evidence
Open the list of active evidence. The period starts from the case start date.
Edit the earning evidence record and set the effective date in the past.
Click on Save.

Resolution:

The dynamic evidence infrastructure has been updated to include a validation preventing a caseworker from specifying an effective date earlier than the business start date if a business start date exists on the evidence. This brings the behavior of dynamic evidence maintenance in line with that of static evidence.

To minimize impact, the validation will not be thrown if existing active evidence with an effective date earlier than the business start date is corrected. It will be thrown if a caseworker continues to edit a piece of pre-existing in-edit evidence on the system.

The validation that has been added is configurable and it's on by default. Its message identifier is as follows:

infrastructuralvalidation.err_controller_effective_date_before_business_
start_date|a|.

PO05235, PO06727, WorkItem:214679 - Loading DynEvdDomain.xml on a cluster environment results in error DynEvdDomain.xml not found which could prevent users from using Dynamic Evidence pages

Issue Description:

The DynEvdDomain.xml is an XML representation of all the Dynamic Evidence domain definitions, and is generated from the Dynamic Evidences on a system. When servers are starting up in a cluster environment each node will trigger loading the DynEvdDomain.xml resource into the APPRESOURCE table. In any scenario which requires reading the domain definitions during execution, it may result in an error stating that the DynEvdDomain.xml resource was not found. This is because each server on the cluster modifies the DynEvdDomain.xml resource when starting up and for a period the resource may be inaccessible.

As a result of the resource being unavailable, this could prevent users from being able to use any Dynamic Evidence page in the application until the server is restarted.

User Interface Impact: Yes (Dynamic Evidence pages may not render.)

Steps to Reproduce:

A user attempts to load a dynamic evidence page which gets called from a cluster node that is in the middle of rebooting.
Once the request hits the server, it fails to initialise and an error is thrown - DynEvdDomain.xml not found.

Resolution:

The code responsible for loading the DynEvdDomain.xml resource into the APPRESOURCE table has been modified to first attempt to read the resource from the database. If the resource already exists, it is then compared to the generated domains. If there is no difference to the stored domains, it will not be reloaded. Only if there is a difference will the resource be reloaded onto the table. This will prevent the error caused by the resource being inaccessible during the startup of a clustered node.

PO07804, WorkItem:231333 - The APIs for PDC Evidence display show the current evidence at the bottom of the list

Issue Description:

A previous enhancement - New Evidence APIs for PDC Evidence display - introduced three new APIs on the PDCPerson façade for listing evidence associated with a Person:

PDCPerson.listCurrentParticipantEvidenceByTypes
(PersonAndEvidenceTypeList)
PDCPerson.listParticipantEvidenceByTypes
(PersonAndEvidenceTypeList)
PDCPerson.searchParticipantEvidenceByDateRange
(SearchParticipantEvidenceByRangeKey)

However, the APIs incorrectly returned open (no end dated) entries last instead of first, which was the intention.
User Interface Impact: Yes

Steps to Reproduce:

For customers who availed of and are using these new APIs:
Register a Person.
Register three new pieces of evidence, with one open-ended.
Go to the Evidence tab, and then the Evidence Group.
Currently active evidence shows last in the list when it should be first.

Resolution:

The APIs have now been updated to produce the desired behaviour. The evidence will now show in the correct order.

EVIDENCE MAINTENANCE

PO07819, WorkItem:237073 - Discarding an In-edit Evidence causes an unhandled server exception to be thrown

Issue Description:

An un-handled server exception is thrown when a user attempts to discard in-edit evidence where the underlying evidence descriptor does not have a participantID set. This cannot ordinarily arise through the standard evidence maintenance functionality, but could arise if data is migrated to Merative SPM from a legacy system without a participantID specified.

User Interface Impact: No

Steps to Reproduce:

Register a Person.
Create an Integrated Case.
Add evidence to the Integrated Case, but do not activate it.
In order to reproduce the issue, the participantID on the underlying evidence descriptor needs to be set to null.
Now attempt to discard the evidence from the evidence workspace.
Issue: an un-handled server exception is thrown.

Resolution:

The Evidence API has been made more robust and is now able to handle a blank participantID when evidence is being discarded.

WorkItem:237075 - An unhandled server exception occurs on creating evidence without entering a participant

Issue Description:

An issue existed across the out-of-the-box dynamic evidence types whereby the Case Participant to be captured was

a) Not marked as mandatory
b) Not defaulted to blank

Marking a field as mandatory is the easiest way of ensuring that it is not left blank when a record is being created through the user interface.

Defaulting the Case Participant drop-down to blank is the best way of ensuring that the wrong participant is not saved when a dynamic evidence record is being created through the user interface, i.e. the caseworker must select the correct participant from the drop-down.

Validations were previously added to the meta-data of a sub-set of dynamic evidence types to validate against the Case Participant being left blank. However, these were not applied to all types and the behaviour was inconsistent.

For evidence types where the validation was not applied, this resulted in unhandled server exception errors during creation of the evidence.

User Interface Impact: Yes

Related WorkItems: 220380, 105444

Steps to Reproduce: Refer to the steps to reproduce provided in the related work items for examples of how to reproduce this issue.
Resolution:

The following corrections have been made to the latest version of dynamic evidence to ensure that a case participant is entered when required so that errors no longer occur when evidence is created:

a) Case Participant marked as mandatory
b) Case Participant defaulted to blank

a) Case Participant marked as mandatory

The Case Participant drop-down field has been marked as mandatory. In instances where 'All Panels' has been specified in the meta-data, i.e. a Case Participant can be selected in a drop-down, a participant can be searched for, or a new participant created, it is not possible to mark the drop-down as mandatory.

b) Case Participant defaulted to blank

For those fields where the Case Participant has been marked as mandatory, the behaviour of the drop-down has been updated to default the field to blank. This means that the caseworker must select the correct case participant before saving the record. If a case participant is not selected, a validation 'Case Participant must be entered' is displayed.

When a dynamic evidence types is created for a case participant, the case participant field appears as read-only on the modify screen.

Note: Taking on these changes requires an insertion of the updated lob data into the database. The associated upgrade steps are outlined in the Merative SPM Upgrade Guide in the chapter entitled 'Correcting metadata for existing dynamic evidence types'.

WorkItem:237078 - 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 recognising 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.

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a tax filer with income of $20,000, and an application date of 8/7/2017.
Submit and authorize application.
Edit the Tax Filing Status record of 'Tax Filer' and set effective date to 9/1/2017 and change type to 'Non-Filer'.
- Apply changes.
End date the Tax Filing Status record of ‘Non-Filer’ to 9/20/2017.
- Apply changes.
Create a new Tax Filing Status record of type ‘Non Filer’, with start date 9/21/2017.
- Apply changes.
End date the Tax Filing Status record of ‘Non-Filer’ to 9/24/2017.
- Apply changes.
Create a new Tax Filing Status record of type ‘Tax Filer’, with start date 9/25/2017.
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.

WorkItem:239138 - Inconsistent Label and Cluster Titles on Participant Data Case Dynamic Evidence Types

Issue Description:

Case Participant label and cluster titles are inconsistent on Participant Data Case dynamic evidence types. Label/cluster titles are missing on some and referred to as Participant on others.

User Interface Impact: Yes

Steps to Reproduce: N/A

Resolution:

Integrated Case Management

PO07512, WorkItem:214413 - Meeting minutes wizard displaying gender code rather than description

Issue Description:

When a case worker is using the meeting minute wizard to capture meeting minutes, one of the optional steps they can do, is provide information about users that have participated in that meeting. This information is captured in the Attendance page in the wizard. When the attendee was selected using the 'Participant/User' drop down, information such as the participants name, their role and gender is displayed. The gender was however displaying as a code, rather than using recognisable terms, such as, 'Male' or 'Female'.

**User Interface Impact: **No

Steps to Reproduce:

Log in as a caseworker.
Register a person.
Create a new Integrated Case.
Open the newly created Integrated Case.
Select the 'Contact' tab.
Click on the 'Meeting Minutes' link.
Select the 'Record Meeting Minutes' button.
When the wizard opens, click 'Next'.
Enter all the mandatory fields on the 'Details', 'Notes' and 'Decisions' pages.
Click 'Next'.
Click 'Next" until the step 4 'Attendance' section.
Select the 'Participant/User' drop-down.
The information shown contained in the drop-down contains participant details, followed by the codes 'SX1' or 'SX2', where 'SX1' and 'SX2' refer to gender terms 'Male' and 'Female', respectively.

Resolution:

This issue has been resolved. Now the participant information displayed in the drop-down contains the correct gender terms, 'Male' and 'Female'.

PO07695, WorkItem:225540 - Cannot overlap special caution dates after disabling validation "specialcaution.err_specialcaution_xrv_category_and_type_
overlaps_in_specified_date_range|a|"

Issue Description:

If an agency requires that special cautions of the same type overlap for the same period, it is not sufficient for an administrator to disable only the following validation:

specialcaution.err_specialcaution_xrv_category_and_type_overlaps_in_
specified_date_range|a|

**User Interface Impact: **No

Steps to Reproduce:

Log on as SysAdmin, then search for and disable the following validation: specialcaution.err_specialcaution_xrv_category_and_type_overlaps_
in_specified_date_range|a|
Log on as a caseworker and open one of the default Smith cases.
Click the Issues and Proceedings tab, then create a special caution, for example, Safety Alert, Victim Tendency, 3/11/2018 - 3/22/2018, and save it.
Create another special caution, for example, Safety Alert, Victim Tendency, 3/21/2018 - 4/12/2018.
Attempt to save the special caution. A validation error is displayed because the dates overlap.

Resolution:

To enable special cautions of the same type to overlap for the same period, also disable the following validations:

specialcaution.err_specialcaution_xrv_category_and_type_overlaps_
in_specified_date_range|a|
specialcaution.err_specialcaution_xrv_category_and_type_overlaps_
in_specified_date_range|a|1
specialcaution.err_specialcaution_xrv_category_code_and_type_
code_exist|a|
specialcaution.err_specialcaution_xrv_category_code_and_type_
code_exist|a|1

For more information, see https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

ELIGIBILITY & ENTITLEMENT

PO05523, WorkItem:101808 - Following multiple reassessments of overpayments the result is incorrectly reflected on the Payment Correction case

Issue Description:

Multiple changes occurred on a case which resulted in a series of overpayments. The last of these overpayments was incorrectly created in the Payment Correction case as an underpayment and the amount on the Payment Correction context panel was incorrect.

User Interface Impact: No

Steps to Reproduce:

Choose a product which uses a CREOLE ruleset, pay in advance delivery pattern and with monthly frequency.
Create a Product Delivery Case with certification start & end dates 01/Mar/2015 - 28/08/2015.
Add and activate evidence such that the client is eligible for payment. Activate the case.
After the case is assessed for the first time, there will be a Financial Component created with start and end dates as 01/03/2015 - 28/08/2015.
Run the Generate ILI batch with processingToDate as 01/May/2015.
This will process the first 3 months payments and there will be 3 ILIs created until 31/05/2015.
Now modify the case start date to 01/05/2015 and trigger the reassessment.
After the reassessment, an overpayment will be created for the amount paid for the first 3 months and with NomineeOverUnderPayment start & end dates as 01/Mar/2015 till 31/May/2015.
Now run the Generate ILI one more time with processingToDate as 01/June/2015.
This will generate the ILI for the month of June.
Now end the case with endDate as 25/05/2015 and trigger the reassessment.
The overpayment was correctly represented on the case but clicking on the case reference number to open the associated Payment Correction Case highlighted some problems.The Payment Correction case was an underpayment and the amount shown on the context panel of the Payment Correction case was incorrect.

Resolution:

This issue is no longer occurring. Multiple overpayments throughout the lifetime of the case are correctly represented on both the case itself and on the Payment Correction case(s).

WorkItem:229374 - Creation of financial components should consider objective tag values during the roll-up of virtual components

Issue Description:

When financial components are being created from case decisions, contiguous components with the following matching criteria are merged or rolled up.

Concern
Objective
Product Delivery Pattern
Related Reference
Value (Objective)

When a financial product is configured, the associated rule-set will have objective tags governing how much gets paid daily, weekly, monthly etc.

For products paid weekly, where clients can be certified for less than a week, organizations would typically have a daily amount that would constitute the daily tag, and then a weekly amount (tag) that would be the daily amount multiplied by either 5 or 7. If the clients are always certified for full weeks, there may be no daily tag at all but only a weekly tag indicating what clients get paid weekly.

For products paid monthly, where clients can be paid for part of a month, the organization may have daily, weekly and monthly tags. The weekly amount would typically be a multiple of the daily amount, with the monthly amount being the daily amount multiplied by 30 (or possibly by the number of days in the month).

It is also possible to configure a product where the monthly tag is a fixed amount (flat rate for each month) and the daily amount (tag) is calculated as the monthly amount divided by the number of days in that month. With this configuration, the daily amount in two consecutive months like February and March would be different. Previously the rollup of financial components did not consider this type of product configuration. For a case certified from the middle of February to the middle of March, for example, the above rolling up logic means the components for February and March are rolled up since they have the same monthly value, when they shouldn't be rolled up as the calculated daily value will differ for February and March.

User Interface Impact: No
Steps to Reproduce:

Configure a certifiable financial product.
Associate a rule-set with it which has two tags, daily and monthly.
Ensure that the daily amount (tag) is calculated as the monthly amount divided by the number of days in that month.
Create a product delivery for the new product, certifying it from the middle of February to the middle of March.
Add a monthly amount as Income evidence on the product delivery.
Approve and activate the case.
Issue: Only one financial component is created using the daily tag amount for February rather than two separate component one for February, for its daily tag amount and one for March for its daily tag amount. The components were incorrectly rolled together as the tag value was not considered in the rollup.

Resolution:

The reported issue has been resolved by including the objective tag values as part of the rolling up criteria, not just the objective values. As these will be different in the scenario outlined above, the virtual components for February and March will be recognised as different, no rollup will occur and the correct financial component amount will be calculated for both February and March.

EVIDENCE MANAGEMENT

WorkItem:123096 - Mechanism to allow a customer to calculate their own evidence start date

Issue Description

For certain evidence types, the period column that is displayed on evidence list pages might not reflect the true business period for the evidence. For most evidence types, the start of the business period is configured as a start date on the evidence. For evidence where the start of the business period isn't configured, either the evidence does not contain a business start date or the evidence contains a start date that has not been defined as the business start date. In such scenarios, the system uses the case start date to represent the start of the business period on evidence list pages. The case start date might not represent the true business start date, and customers might want to default to an alternative date instead.
**User Interface Impact: **No

Steps to reproduce

Log on as a caseworker.-
Register a person, Jane Doe, with a birth date of '1/1/1970'.
Click the Evidence tab.
The period column for both Jane's 'Names' evidence and 'Birth and Death Details' evidence starts from the registration date.
Customers might prefer that the period column represents Jane's evidence as starting from, for example, Jane's date of birth.

Resolution

A new custom hook has been provided through the EvidencePeriodHook interface that enables customers to configure values that override the business start and end dates in the evidence list pages. For certain evidence types, if the period that is displayed in the evidence list page does not represent the true business period, customers can now overwrite the period to define their own business start date. Customers need to implement the custom hook for evidence types whose business start and end dates they want to override, with each implementation being bound to its respective evidence type.

PO07636, WorkItem:222216 - On creating a static child evidence with a preassociation relationship 'curam.core.sl.infrastructure.struct.ParentList' is not being imported

Issue Description:

Changes made to the evidence generator ServiceLayerImports.xslt stylesheet during 7.0.2.0 resulted in the incorrect removal of the 'curam.core.sl.infrastructure.struct.ParentList' import. This caused issues for customers who had pre-association tags defined, as the generated code for pre-association tags depends on the import being present.

There are no examples of pre-association relationships out-of-the-box, but a description of what they are and when they should be used can be found here in the documentation - https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation\\
User Interface Impact: No
Steps to Reproduce:

Create a static child evidence with a pre-association relationship.
Generate the code and observe the build logs to see see a warning that 'curam.core.sl.infrastructure.struct.ParentList' is not being imported.

Resolution:

This issue is now resolved and 'curam.core.sl.infrastructure.struct.ParentList' is imported correctly.

Technical:

The following import

'curam.core.sl.infrastructure.struct.ParentList'

has been reinstated in the

.\Tools\Generators\EGTools\components\evidence\xsl\
ServiceLayerImports.xslt

static evidence generator stylesheet artifact.

Customers with the following metadata defined for an evidence entity

<Relationships>
<PreAssociation to="AnotherEntityType"/>
</Relationships>

will suffer from this problem.

WorkItem:234258 - 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:

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.
Create the necessary cases and add the evidence, parent, child, grand-child etc.
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.
When viewing the product delivery, the page for listing the verifications should be visible.
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.

COMMON

PO07494 PO07677 , WorkItem:213970 - An attachment for a case can still be downloaded after it has been deleted

Issue Description:

The Contact Log Attachments page shows a downloadable link to a cancelled attachment. Case Attachments also show a downloadable link to a cancelled attachment. When an attachment is cancelled it should not be downloadable or viewable.
User Interface Impact: Yes

Steps to Reproduce:

Log in as a caseworker.
Register a Person and create a Social Assistance case.
Go to 'Contact' tab.
Go to the 'Attachments' navigation tab.
Select 'New'.
Enter the mandatory fields on the 'New Attachment' modal dialog. Browse for File and add Description.
Click 'Save'.
On the 'Attachments' list page, click on the toggle to open the attachment inline page.
The information shown in the Name field shows a link for the filename.
On the 'Attachments' list page click on the row level menu items and select 'Delete'.
Answer 'Yes' on the Delete Attachment modal dialog.
On the 'Attachments' list page click on the toggle to open the attachment inline page.
Issue: The information in the Name field still shows a link for the filename.

Resolution:

The functionality has been updated so that if the status of the attachment is ‘Canceled’, the filename is shown as normal text and not as a link.

INCIDENTS

PO07531, WorkItem:215157 - Meeting Minutes PDF generated with HTML tags invalidly displayed

Issue Description:

Previously, when meeting minutes were being recorded on a case there were junk HTML tags added in some of the fields of the pdf document produced under the option 'View Printer Friendly Minutes'.

**User Interface Impact: **No

Steps to Reproduce:

Log in as a caseworker.
Register a Person and create a Social Assistance case.
Open the Contact tab.
Select Meeting Minutes.
Click on Record Meeting Minutes and create meeting minutes.
Add Agenda, Notes and Decisions.
Now from the Meeting Minutes row level action menu, click on 'View Printer friendly Minutes'.
Issue: In the PDF document there are HTML tags added under the 'Agenda', 'Decision' and 'Notes' columns.

Resolution:

The issue is now resolved and the fields 'Agenda', 'Decision' and 'Notes' only show the expected text in the PDF document.

PARTICIPANT MANAGEMENT

PO07682, WorkItem:224538 - The CONCERNROLE.REGUSERNAME attribute is not correctly populated when registering an existing Prospect Person as a Person

Issue Description:

When a Prospect Person has been registered in the system by one user and then a different user has performed a Person Registration, the system should record the username of the user who has performed Person Registration. The issue exists where CONCERNROLE.REGUSERNAME is not correctly populated when registering an existing Prospect Person as a Person.

After registering a Prospect Person as a Person, the 'REGUSERNAME' column value still contains a username of the user who has registered the Prospect Person instead of the username of the user who performed Person Registration.

**User Interface Impact: **No

Steps to Reproduce:

Log in as caseworker user and Perform a 'Prospect Person' registration for John Smith.
View the ConcernRole table. Note that REGUSERNAME = caseworker, which is correct.
Log out.
Log in as superuser.
Search for 'John Smith' registered as a Prospect Person in previous steps and perform a 'Person Registration'.
View the ConcernRole table. Note that REGUSERNAME = caseworker.
Issue: In the previous step, REGUSERNAME should be set to superuser.

Resolution:

The issue has been resolved and now the value in the CONCERNROLE.REGUSERNAME table column will be correctly recorded when a different user performs a Person Registration of the Prospect Person already present in the system.

Application Development Environment

CLIENT DEVELOPMENT ENVIRONMENT

PO07432, WorkItem:229425 - A pop up unexpectedly appears when a user selects a Save action and the focus of the mouse changes

Issue Description:

Previously, a pop up unexpectedly appeared when the caseworker moved the mouse outside of the browser while the application was processing an action, for example, submitting a form or navigation between the tabs into the application.

**User Interface Impact: **No

Steps to Reproduce:

Login to the application.
Create a case, containing a number of members.
Edit multiple evidence types.
Apply the changes and immediately hover the mouse icon over the new browser tab (or press Alt+Tab)
The browser dialog confirmation is displayed with the button Leave and Stay.

Resolution:

The issue has been resolved by adjusting how we listen for the event that controls the browser dialog confirmation.

PO07808, WorkItem:231379 - The validation message for an incorrect start date while creating new Contact Log repeats the word 'date'

Issue Description:

Incorrect Start Date validation message while creating a new Contact Log. The message says 'Date' twice - 'Start Date Date'.

User Interface Impact: Yes

Steps to Reproduce:

Log in as a caseworker.
Register a Person and navigate to Issues and Proceedings > Incidents.
Create a new incident record.
From the list of incidents record, click on the 'Type' link of the created record, which opens the incident home page.
Navigate to the Contact Log.
Navigate to 'New Contact..'.
On the New Contact screen, clear the 'Start Date'.
Click 'Next'.
Issue: An incorrect validation message is displayed: ''Start Date Date' must be entered'.

Resolution:

This issue has been resolved and the word 'date' does not appear twice in the error message reported. The issue was resolved by rendering the incidentWizardDetails.wizardDetails.contactDetails.
startDateTime property correctly.

PO07333, WorkItem:237077 - Page level PRINT icon does not print the Details section of expanded evidences in evidence list

Issue Description:

Previously, when using the page level Print icon to print a list of Evidence details, certain information was missing. When the evidence was expanded to display the full details associated with the evidence, only the Change Summary information was printed. No information from the Evidence Details page was printed.

User Interface Impact: No

Steps to Reproduce:

Login as a caseworker.
Register a Person.
Create a Case.
From the Evidence dashboard, create a new Evidence.
Activate the Evidence.
View the newly created Evidence from the Active Evidence list.
Click the toggle to view the Change Summary for the evidence.
Click the toggle to view the Evidence Details associated with the evidence.
Print the page using the print button in the options menu of the page.
The only information present in the print preview is the Change Summary information.

Resolution:

This issue has been resolved by adding specific styling for Evidence pages when they are printed. This ensures all the visible Evidence information is printed correctly.

PO07333, WorkItem:237080 - Page level PRINT icon does not print the Details section of expanded evidences in evidence list

Issue Description:

Login as a caseworker.
Register a Person.
Create a Case.
From the Evidence dashboard, create a new Evidence.
Activate the Evidence.
View the newly created Evidence from the Active Evidence list.
Click the toggle to view the Change Summary for the evidence.
Click the toggle to view the Evidence Details associated with the evidence.
Print the page using the print button in the options menu of the page.
The only information present in the print preview is the Change Summary information.

Resolution:

This issue has been resolved by adding specific styling for Evidence pages when they are printed. This ensures all the visible Evidence information is printed correctly.

PO07507, WorkItem:237082 - Page level PRINT icon does not print Notes History or Search Results correctly

Issue Description:

Previously, when a user selected the page level print to print Notes or Search Results, not all of the information that was displayed to the user was printed. When the Search Results or Notes were expanded to show the inline page containing the all the information available, the information in the inline page was not printed correctly.

**User Interface Impact: **No

Steps to Reproduce using Search:

Login as a caseworker.
From the Shortcuts area of the Cases and Outcomes section, select 'Person'.
Enter criteria and search for a person on the system.
When the search is completed, expand the toggle associated with one of the search results, so that more participant information is visible.
Print the page using the print button in the options menu of the page.
Not all of the information is present on the print preview.

Steps to Reproduce using Notes:

Login as a caseworker.
Register a Person.
Click on the Contact tab.
Create multiple notes.
Expand the toggle associated with one of the Notes, so that the note is visible.
Print the page using the print button in the options menu of the page.
Not all of the information is present on the print preview.

Resolution:

This issue has been resolved by adding specific styling to pages as they are printed. This ensures all information on the Person Search page and Notes is printed clearly.

WorkItem:237481 - Landscape print layout disappears when trying to print any page using page level print icon

Issue Description:

Previously there was an issue regarding displaying print layout options specifically on the Chrome browser.

**User Interface Impact: **No

Steps to Reproduce:

Login as a caseworker.
From the Shortcuts area of the Cases and Outcomes section, select 'Person' under the 'Search' drop-down.
Click on the print button in the options menu of the page - the layout option is not present.

Resolution:

This issue has been resolved by editing specific styling which was affecting print layout options specifically on the Chrome browser.

ACCESSIBILITY

WorkItem:193191 - Tablet Accessibility: Unable to re-select blank item from drop down list

Issue Description:

A drop-down list displayed in the mobile (tablet) environment was not fully accessible when it contained the blank option; this option could not be re-selected by the user using a keyboard or gestures.

**User Interface Impact: **No

Steps to Reproduce:

Navigate to the Person Registration page on iPad with the VoiceOver screen reader.
Using keyboard or gestures navigate to the Gender drop-down on the registration page.
Using the supported combination open Gender drop-down and select one of the non-blank values from the list.
Navigate to another form field using keyboard/gestures.
Navigate back to the Gender drop-down and open the list.
Using keyboard/gestures try re-selecting the first (blank) option. It is not selectable this way.

Resolution:

The drop-down control previously used in the mobile environment has been replaced by the widget which supports the blank option selection/re-selection. The blank-option text read by the screen readers can now be customized. It is now controlled by the application-wide property:

text.select.blankoption.description

which is located in CDEJResources.properties and can be customized/localized the same way as any other property contained in the CDEJResources.properties file.

PO07727, WorkItem:227106 - Merative SPM Accessibility - JAWS doesn't indicate that the transition from one wizard step to the next is completed

Issue Description:

The JAWS screen reader did not always portray information about the currently active tab which was visually highlighted in a modal progress wizard toolbar.

User Interface Impact: No

Steps to Reproduce:

Start the JAWS screen reader.
Login as caseworker.
Open the Cases and Outcomes tab.
Open the Shortcuts menu.
Open the Registration section by clicking on the toggle and select Person.
Click 'Next'.

Resolution:

The JAWS screen reader will now announce visually highlighted information on the progress wizard toolbar.

WorkItem:227148 - Expand and Collapse toggle arrows on a section in the page does not work with apple Voiceover when using double click or Voiceover key and Enter command

Issue Description:

Previously, where there were Expand / Collapse toggle arrows on a section in the page, they did not work correctly when using Voiceover. The entire width of the page was highlighted and double-clicking the arrow, or using the Voiceover key and Enter command, did not expand / collapse the section as expected.

User Interface Impact: Yes

Steps to Reproduce:

Login in as a caseworker.
Open a page that displays an Expand / Collapse toggle section page such as Person Search.
Enable Voiceover.
Navigate through the page using the keyboard until you reach the section Expand / Collapse arrow.
Just the arrow should be highlighted.
Double-click on the page should expand/collapse the section.
Using the Voiceover key and enter should also Expand / Collapse the section.
The section is not expanded as expected.

Resolution:

The issue has now been resolved by updating the HTML tag of the Expand / Collapse arrow.

PO07793, WorkItem:230524 - JAWS screen reader reads the tabular structure where it is used for layout purpose

Issue Description:

JAWS 2018 reads the tabular structure of the first field in a form followed by the actual field name (for example “Table Column 2 Row 1 First Name”). JAWS should just read the field name.
User Interface Impact: No

Steps to Reproduce:

Login as a caseworker.
Navigate to Person Search page.
Start JAWS 2018.
Tab on the page to the first input field in a form.
JAWS reads out the field name and the tabular structure.

Resolution:

This issue is now resolved and JAWS 2018 no longer reads out the structure of the fields in a form.

PO07807, WorkItem:231124 - Color Contrast correction for Calendar

Issue Description:

In the UI's Calendar widget the color for today's date fails Level AA Conformance to Web Content Accessibility Guidelines. This is due to the background-color being light-blue (#9FBBDE) and the font-color being white (#FFFFFF). This impacts users with impaired vision, preventing them from distinguishing the dates available in the Calendar.
**User Interface Impact: **Yes

Steps to Reproduce:

Login as caseworker.
Search for a person registered this month, and click their name to open their profile.
In the Tab Actions menu click 'Edit..'.
Click the Calendar widget next to Registration Date.
Observe that today's date is highlighted with a light blue background-color and white font.

Resolution:

Observe now that the font color is now black which conforms with Level AA Conformance to Web Content Accessibility Guidelines.

PO07816 , WorkItem:231730 - Application screen heading structure used by JAWS navigation missing Level 1 Heading

Issue Description:

Previously, the heading structure of application pages was missing the h1 heading. When using JAWS to navigate the application by pressing Insert+F6, the list of available headings to move to was starting from the h2 heading.

User Interface Impact: Yes

Steps to Reproduce:

Login as caseworker using Internet Explorer 11.
Launch JAWS 2018.
Press Insert+F6 to bring up the lists of headings (on any pages of the Merative SPM Application).
Observe the list of headings in the JAWS dialog. The h1 heading is not displayed in the list.

Resolution:

This issue has been resolved by updating the Application Banner Renderer to create the h1 element. Now 'IBM Cúram Social Program Management' is displayed as h1 in the Heading List on the JAWS dialog when pressing Insert+F6.

PO07996, WorkItem:231858 - Screen reader does not announce the tab titles when moving through the content area tab navigation bar

Issue Description:

When a user searched for a person, opened their home page and moved through the content area tab navigation bar, JAWS screen reader 17 and 2018 ignored the tab title and/or read other elements that were not related to the tab title.
User Interface Impact: No

Steps to Reproduce:

Using JAWS 17 or 2018 with Internet Explorer 11
Login as a caseworker
Navigate to a Person profile page e.g. 'James Smith'
Navigate to the 'Home' tab on the content area tab navigation bar and move through the other tabs such as 'Evidence' and 'Care and Protection'
Observe the extra text being announced or not announced at all.

Resolution:

The issue has been resolved and JAWS now correctly announces the tab titles.

PO07830, WorkItem:232434 - Incorrect labels displayed for Phone Number and Alternate Phone Number fields in an Insurance Affordability application when JAWS screen reader is used

Issue Description:

When creating an Insurance Affordability application from within the Citizen Portal, on the 'Information About You' page, a user can enter both a Phone Number and Alternate Phone Number. For both fields the phone number is entered into two separate text entry fields, one to capture area code and one to capture phone number.

When the JAWS Screen Reader is being used, a user is able to press the Insert+Ctrl+E keys to display a 'Select an Edit Box' modal for use in selecting fields to edit. In this instance, the labels used for the area code and phone number text entry fields that make up the Phone Number field both use the same label of 'Phone Number' and the user is not able to determine which text entry field is for the area code and which is for the phone number. The same issue also occurs with the Alternate Phone Number field.
User Interface Impact: Yes

Steps to Reproduce:

Open JAWS 18.
Open IE11.
Open the Citizen Portal.
Select to apply for assistance, select to create an account to register in the Citizen Portal, and proceed to create an Insurance Affordability application.
Select the 'I agree' checkbox on the 'Before We Get Started' page of the application and click 'Next’.
The 'About You Section' page will open. Click 'Next'.
The 'Information About You' page will display.
When the user presses the Insert+Ctrl+E keys to display the 'Select an Edit Box' modal for use in selecting fields to edit, the labels displayed for the area code and phone number text entry fields that make up the Phone Number field both display the same label of 'Phone Number'.

Resolution:

The area code and phone number text entry fields for the 'Phone Number' and 'Alternate Phone Number' fields both now use separate titles and correctly display in the 'Select an Edit Box' modal, making it possible for a user using the JAWS screen reader to differentiate between the two fields.

Technical:

The issue was resolved by adding the following two properties:

PersonnalDetails.AreaCode.Label=Area Code
PersonnalDetails.SecondPhoneNumber.AreaCode.Label=Alternate Phone Number Area Code

to the following properties files:

../EJBServer/components/HCR/data/initial/blob/prop/HealthCare
CW_V1_Intake_AboutYouPage.properties
../EJBServer/components/HCROnline/data/initial/blob/prop/About
You/HealthCarePortalAboutYouSubScript_V1_SubScript_AboutYou
Page.properties

and then referencing them in the following scripts:

../EJBServer/components/HCR/data/initial/clob/HealthCareCW.xml
../EJBServer/components/HCROnline/data/initial/clob/HealthCare
PortalAboutYouSubScript.xml

PO07826, WorkItem:232452 - Incorrect labels displayed for Phone Number Type and Alternate Phone Number Type fields in an Insurance Affordability application when JAWS screen reader is used

Issue Description:

When creating an Insurance Affordability application from within the Citizen Portal, on the 'Information About You' page, a user can enter both a Phone Number Type and Alternate Phone Number Type.

When the JAWS Screen Reader is being used, a user is able to press the Insert+Ctrl+C keys to display a 'Selectable ARIA controls, comboboxes, listboxes, or treeviews' modal. In this instance, the labels used for the phone number type and alternate phone number type fields both use the same label of 'Type' and the user is not able to determine which field is for the phone number type and which is for the alternate phone number type.
User Interface Impact: No

Steps to Reproduce:

Open JAWS 18.
Open IE11.
Open the Citizen Portal.
Select to apply for assistance, select to create an account to register in the Citizen Portal, and proceed to create an Insurance Affordability application.
Select the 'I agree' checkbox on the 'Before We Get Started' page of the application and click 'Next’.
The 'About You Section' page will open. Click 'Next'.
The 'Information About You' page will display.
When the user presses the Insert+Ctrl+C keys to display the 'Selectable ARIA controls, comboboxes, listboxes, or treeviews' modal, the labels displayed for the phone number type and alternate phone number type fields both display the same label of 'Type'.

Resolution:

The 'Phone Number Type' and 'Alternate Phone Number Type' fields both now use separate titles and correctly display in the modal, making it possible for a user using the JAWS screen reader to differentiate between the two fields.

PO07829, WorkItem:232505 - Combo boxes in IEG scripts were marked as unlabeled in the JAWS 'Select In Edit Box'

Issue Description:

JAWS provides a tool, 'Select In Edit Box', which can be enabled by using the Insert+Ctrl+E key combination. The 'Select In Edit Box' feature should only list fields that a partially sighted user can edit.

When a user enables 'Select In Edit Box' on the Citizen Portal application script, if the page contains a combo box the user sees an unlabeled field in the 'Select In Edit Box'. This is not correct. As a combo box is an editable field, the field name should be displayed.

**User Interface Impact: **No

Steps to Reproduce:

Open JAWS 2018.
Open Internet Explorer 11.
Open the Universal Access landing page and login.
Click the 'Find Government and Community Help' menu item.
Click the 'Check if You are Eligible for Government Benefits' menu item.
Click the 'Enable Medical Assistance Screening' option.
Click 'Next' to access script.
Continue through the script until a combo box is presented to the user.
Using the key combination, Insert+Ctrl+E, enable the 'Select In Edit Box' feature.
Issue: The 'Select In Edit Box' displays fields that are editable, and unlabelled fields.

Resolution:

This issue has been resolved. The 'Select In Edit Box' now displays all editable fields that are contained within the page, including the combo boxes.

PO07875, WorkItem:235158 - Page headers not displayed correctly within an Insurance Affordability application when JAWS screen reader is used

Issue Description:

When creating an Insurance Affordability application from within the Citizen Portal, headings are displayed on the various pages within the application.

When the JAWS Screen Reader is being used, a user is able to press the Insert+F6 keys to display a 'Heading List' modal that lists the headings that are on the page for the user. In this instance, not all headings that are displayed on the page are being displayed in the modal for the user. This prevents the user from being able to correctly identify all headings that exist on a page.

There were five pages affected by this issue, as illustrated in the steps to reproduce.
**User Interface Impact: **No

Steps to Reproduce:

In the Citizen Portal application there are 5 pages affected by this issue. Please refer to the steps below to navigate through the application and access each one of those pages:

Prerequisite: Using JAWS 18 and IE11. The citizen has already created an account.

Open JAWS 18.
Open IE11.
Open the Citizen Portal.
Select to apply for assistance, select to create an account to register in the Citizen Portal, and proceed to create an Insurance Affordability application.
Select the 'I agree' checkbox on the "Before We Get Started" page of the application and click 'Next’.
The 'About You Section’ page will open.
Press Insert+F6 to display the available page headings. The 'Please Tell Us About You', 'What is this Section About' and 'For the section you may need' headings are not present.
Click ‘Next’.
Proceed through the 'Information About You' and 'More About You' pages completing as required.
On the 'Household Section' page, press Insert+F6 to display the available page headings. The 'Please Tell us About Your Household', 'What is this section about' and 'For this section you may need' headings are not present.
Click ‘Next’.
The ‘Other Household Members’ page will display.
Select ‘Yes’ in the ‘Is there anyone else in the household?’ field.
Click ‘Next’.
Proceed through the ‘Household Member Details’, ‘Household Member Extra Details’ and 'More People' pages completing all mandatory fields.
Click ‘Next’.
The 'Relationships' page will open.
Input the required relationships.
Click ‘Next’.
Provide the required information on the 'Tax Filing Status' page.
Click ‘Next’.
The ‘Income Section’ page will display.
Press Insert+F6 to display the available page headings. The 'Please Tell us About Your Household Income', 'What is this section about' and 'For this section you may need' headings are not present.
Click 'Next'.
Enter the required income information and click 'Next'.
The 'Additional Household Information Section' page will display.
Press Insert+F6 to display the available page headings. The 'More About Your Household', 'What is this section about' and 'For this section you may need' headings are not present.
Proceed through the rest of the application until the 'Summary' page.
Press Insert+F6 to display the available page headings. The 'You', 'Your Household', 'Additional Household Information', 'Household Income', and 'Additional Income Information' headings are not present.

Resolution:

Missing tags for the headings that were not being displayed have been added. All headings for each of the pages are now displayed correctly, making it possible for a user using the JAWS screen reader to identify the hierarchy of headings on each page.

PO07882, WorkItem:235746 - Sign and Submit error not read out by JAWS

Issue Description:

When a modal dialog is submitted without having the required fields populated, the JAWS screen reader does not announce the error messages about the required fields.
User Interface Impact: No

Steps to Reproduce:

Start the JAWS screen reader.
Go to the Universal Access portal.
Register a user.
Create an application providing the basic details.
Once you get to the 'Summary' page, click on the 'Sign and Submit' button.
On the modal dialog, do not check one of the mandatory boxes and click on the 'Submit' button.
Issue: JAWS does not announce the errors messages.

Resolution:

The JAWS screen reader now announces the errors messages displayed about the required fields on modal dialog pages.

LOOK & FEEL

PO07436, WorkItem:210071 - Double scroll bars are incorrectly displayed

Issue Description:

On a number of pages double scroll bars are incorrectly displayed due to the use of fixed height scroll-able elements.
**User Interface Impact: **Yes

Steps to Reproduce:

A sample of this issue can be reproduced as follows:
- Login as caseworker.
- Navigate to Register Employer.
- Search for an Employer that is already registered.
- Issue: The result is returned and a double scroll bar is displayed.

Resolution:

This has been resolved by a bulk update to remove the use of fixed height scroll-able elements across the application. Pages that previously used this element now only display a single scroll bar.

PO07592, WorkItem:219388 - The label and field are not properly aligned - Codetable Hierarchy alignment Issue

Issue Description:

In the UI's codetable widget, when a CLUSTER does not have the TITLE attribute defined and a FIELD element contains a Hierarchical Codetable displayed horizontally, the labels are misaligned with the field.

User Interface Impact: Yes
Steps to Reproduce:

Edit webclient\components\core\System\Document Template\System_createDocumentTemplate1.uim
Remove the Title for the CLUSTER and add Label for the Field - see the Technical section for details.
Build the client.
Log in as sysadmin.
Go to Communications > Microsoft Word Templates > New
Issue: Observe that the label and fields are misaligned.

Resolution:

Now the label and field for the codetable widget are aligned correctly.
Technical:

PO07711, WorkItem:226337 - Fields misaligned on Relationship Evidence modal dialog

Issue Description:

The Area Code and Phone Number fields on the Relationship Evidence dialog were misaligned.
User Interface Impact: Yes

Steps to Reproduce:

Login as a caseworker.
Register a Person.
Go to the Evidence tab of the Person home page.
Select to add new Relationships evidence.
Issue: Observe that the Area Code and Phone Number fields are misaligned with the other fields.

Resolution:

The Area Code and Phone Number fields on Relationship Evidence are now aligned with the other fields on the page.

PO07708, WorkItem:227605 - The '*required field' label is missing in Dynamic Evidence details screens

Issue Description:

The '*required field' label is not visible on Dynamic Evidence details screens where there are required fields present.
User Interface Impact: Yes

Steps to Reproduce:

Login as hcrcaseworker.
Register a Person.
Go to Person home page.
Start a 'New Application' from the page level menu.
Complete and submit an Insurance Affordability application.
Go to the Insurance Affordability application case home page.
Navigate to Evidence > New Evidence > DHSID Details.
Issue: Add details and observe there is no '*required field' label on the screen.

Non Healthcare Reform Steps to Reproduce:

To observe above behavior in a non HCR application, please configure dynamic child evidence. Navigate to it and observe the missing '*required field' label.
Resolution:

This issue has been resolved by updating the css styling to display the required field label that was previously hidden from view.

PO07905, WorkItem:237491 - The mandatory field label '*required field' not displaying on Edit Priority modal

Issue Description:

The mandatory field label '*required field' was not displaying on Edit Priority modal when user has been editing Task priority.
User Interface Impact: Yes

Steps to Reproduce:

Login as a caseworker.
Navigate to the Inbox.
Navigate to My Tasks.
Create a New Task.
Enter a subject title and click the checkbox to 'Add to My Tasks'
Click 'Save'.
Navigate to the new task in My Open Tasks.
Select the action menu on task and select Edit Priority.
Issue: Observe the '*required field' label is present.

Resolution:

This issue has been resolved by updating the css styling to display the required field label that was previously hidden from view.

WIDGETS

PO07806 , WorkItem:231399 - Home page pod customization fields not aligned with checkbox

Issue Description:

Home page pod customization fields not aligned with check-box when the pod page is set to 4 or more columns.
User Interface Impact: Yes

Steps to Reproduce:

Numbered steps on how to create the scenario that would have resulted in the issue that has been resolved.

Log in as admin.
Navigate to Shortcuts > User Interface.
Go to 'Personalized Pod Pages'.
Edit in the list 'CaseWorkerCustomHome'.
Change the number of columns from 3 to 4.
Login as caseworker.
Go to the 'Home Page'.
Push the 'Customize' button on the top right of page.

Resolution:

Previously, the check-boxes was not aligned with the labels for more than three columns have been set. Now they are also aligned for more than 3.

INSTALLER DEVELOPMENT ENVIRONMENT

WorkItem:237607 - Incorrect documentation for minimum application transaction timeout settings for WebLogic

Issue Description:

In the 'Configuring the Weblogic application transaction timeout settings' section of the Installation guide the minimum application transaction timeout setting for Weblogic is incorrectly recommended to be 600 seconds for the following components:

Merative Social Program Management Child Welfare
Merative Social Program Management Income Support
Merative Social Program Management Income Support for Medical Assistance
Merative Social Program Management Workers Compensation
Merative Social Program Management Youth Services

User Interface Impact: No

Resolution:

The documentation has been updated to now recommend 120 seconds for the minimum application transaction timeout setting for Weblogic. For more information, see https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

SERVER DEVELOPMENT ENVIRONMENT

WorkItem:159527 - Additional details for the static KeyServer property 'curam.keyserver.keyset.cachesize' are now available

Additional details for the static KeyServer property 'curam.keyserver.keyset.cachesize' are now available.

Set the property curam.keyserver.keyset.cachesize to control the number of unique ID key sets that are consumed and cached per KeyServer transaction to optimize your batch program execution.

The additional information includes the following three examples:

Specifying a key server cache size of 20 for all batch programs
Specifying a key server cache size of 20 for a single run of the batch launcher
Specifying a key server cache size of 20 for a single run of the batch launcher for a single batch program named CloseCasesPendingClosure.closeCasesPendingClosure

For more information about the curam.keyserver.keyset.cachesize static KeyServer property, see https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

XML SERVER

PO07422, WorkItem:209377 - Exception thrown by the XML Server when generating a PDF file which contains references to images due to a missing xml-apis-ext.jar

Issue Description:

An exception was thrown by the XML Server when generating a PDF file which contained references to images. This was due a missing JAR called xml-apis-ext.jar. As part of a previous FOP upgrade, the actual FOP deliverable placed classes which were previously delivered in the batik-all.jar file (which is shipped with the product) and moved them into a new JAR called xml-apis-ext.jar. This JAR was not shipped and hence when the rendering of images use case was invoked in the XML Server, the required classes could not be found and the exception occurred.
User Interface Impact: No

Steps to Reproduce:

Modify an XSL template used in the generation of a PDF file to add an <svg> tag into the document. This tag may be used to draw some graphics in a PDF (i.e. such as lines and check boxes as the example below specify).
An example of this mark up is shown below.

Generate the PDF using a template containing the specified mark up and an exception will be thrown outlining that the "org/w3c/dom/svg/SVGDocument" and "org/w3c/css/sac/Parser" classes could not be found.

Resolution:

The issue has been resolved by the addition of the missing JAR (xml-apis-ext-1.3.04.jar) into the SDEJ deliverable. This JAR has now been placed into the 'CuramSDEJ/xmlserver' directory and all of the relevant build time and run time scripts have been updated accordingly.

Business Services

TASK MANAGEMENT

PO07407, WorkItem:208139 - User is unable to cancel out of Add To My Tasks

Issue Description:

When trying to assign multiple tasks in the Available tasks page the user was unable to cancel out of 'Add To My Tasks' screen as the 'No' icon was not returning the user to the previous page as it should. To go back to the list of tasks available, the user needed to close the tab and start the process again.
User Interface Impact: Yes

Steps to Reproduce:

Log in as caseworker.
Use the 'Create Task' option in the My Tasks pod to create a task and assign it to superuser.
Log in as superuser.
Go to the Inbox.
In the Shortcuts Click on Available tasks.
Select the task.
Click on the 'Add to My Tasks' link at top of the page.
Clicking on No does nothing as the icon is not working.

Resolution:

Now when the user wants to cancel out of the Add to My Tasks, the 'No' icon will redirect the user to the previous page with tasks available for selection, and a new selection can be performed.

Common Intake

PO06188, WorkItem:154913 - Date of Birth field incorrectly defaults to the current date when adding a client to an application case

Issue Description:

When selecting the 'Add Client' option on an Application case to add a person to that application, the 'Date of Birth' field on the 'Add Client' modal defaults to the current date.

**User Interface Impact: **No

Steps to Reproduce:

Login as a caseworker.
Select the 'Cases and Outcomes' tab.
In the Shortcuts Panel select Searches > Person.
Search for a person who has already been registered and navigate to the Person Home page.
On the Person Home page select 'New Application Case..' from the actions menu.
On the 'New Application Case' modal choose one of the application types from the drop down menu and click 'Save'.
Within the new Application Case select 'Add Client..' from the actions menu.
On the 'Add Client' modal observe that the value of the 'Date of Birth' field defaults to the current date.

Resolution:

The 'Date of Birth' field on the 'Add Client' modal now defaults to a blank value allowing the caseworker to enter the correct date of birth for the person being added to the application.

Technical:

The CommonIntake_addClient.uim page inside the CommonIntake component has been modified to ensure the date of birth field defaults to blank. That is, the USE_DEFAULT="false" flag has been added to the field with LABEL="Field.Label.DateOfBirth".

ADMINISTRATION

PO07703, WorkItem:225885 - Unable to properly interact with the first editable field initially focused on when a page is opened in a tab or modal dialog on Internet Explorer with JAWS enabled

Issue Description:

Previously there was an issue where the first editable element (such as an input text box field or filtering select dropdown) was initially not being focused on correctly when a page or modal dialog was opened. This issue was present on Internet Explorer when the JAWS screen reader was enabled. In order to interact with this first editable element, a user was forced to tab to another element and then tab back to the first editable element.

User Interface Impact: No

Steps to Reproduce:

Scenario 1:

Enable the JAWS Screen Reader and use Keyboard navigation for the following steps.
Log into the application on Internet Explorer as ccsintakeworker.
Click on the Intakes tab.
In the Shortcuts menu under Intakes select 'New Intake'.
When the modal dialog opens and the dropdown labelled 'Category' is highlighted, select a value from the dropdown.

Scenario 2:

Enable Jaws Screen Reader and use Keyboard navigation for the following steps.
Log into application on Internet Explorer as ccsintakeworker.
Click on the Intakes tab.
In the Shortcuts menu under Registration select 'Person...'.
When the modal dialog opens and the text field labelled 'Reference Number' is highlighted, enter a value into this highlighted text field.

Resolution:

This issue has been resolved by implementing a new approach around the timing of focusing on the first editable element of the page.

Cúram Modules

Outcome Management

PO06457, WorkItem:167513 - Unhandled server exception occurs when navigating to the home page of an action that has a frequency of 'Bi-monthly'

Issue Description:

Within an outcome plan, caseworkers are able to create actions and as part of creating an action specify a frequency for how often the client is expected to participate in the action. When a caseworker creates a new Action and selects a bi-monthly frequency pattern for the client participation, the caseworker then receives an error when trying to navigate to the Action home page.
User Interface Impact: No

Steps to Reproduce:

Login as a caseworker.
Create a new Outcome Plan for a registered person.
Within the Outcome Plan, navigate to the Activities tab and select to create a new Action.
On the Schedule step of the New Action wizard, select a frequency pattern of 'Bi-monthly'.
Complete the creation of the Action using the wizard.
Select the newly created Action from the list of activities on the Activities page.
An unhandled server exception is displayed on the Action home page.

Resolution:

A caseworker can now view information on the Action home page when the action has a frequency pattern of 'Bi-monthly'.

PO07780, WorkItem:229620 - Within an outcome plan the Progress chart is not correctly displayed on the Factor home page after the progress for a factor is updated

Issue Description:

Caseworkers are able to add factors to an outcome plan and update progress for the factors. When a caseworker updates the progress for a factor and then navigates back to the 'Factor' home page, the Progress chart that is displayed is not correctly updated to display the progress updates that were entered.
User Interface Impact: Yes

Steps to Reproduce:

Login as a caseworker.
Create a new Outcome Plan.
Navigate to the 'Factors' page under the 'Assessments & Factors' tab and select to add a factor and a rating.
Select the factor to navigate to the 'Factor' home page.
Navigate to the 'Progress' tab and update the progress of the factor.
Navigate back to the 'Factor' home page.
The Progress chart is not correctly updated on the 'Factor' home page.

Resolution:

The progress chart now displays correctly on the 'Factor' home page.

PO07786, WorkItem:230205 - Within an outcome plan the Factor home page does not display correctly after the progress for a factor is updated

Issue Description:

Caseworkers are able to add factors to an outcome plan and view information about a factor on various pages within the Factor tab. When a caseworker updates the progress for a factor and then attempts to navigate back to the 'Factor' home page, the icon that is displayed to indicate that a page is loading is displayed indefinitely and the 'Factor' home page does not display.
User Interface Impact: Yes

Steps to Reproduce:

Create a new Outcome Plan.
Navigate to the 'Factors' page under the 'Assessments & Factors' tab and select to add a factor and a rating.
Select the factor to navigate to the 'Factor' home page.
Navigate to the 'Progress' tab and update the progress of the factor.
Navigate back to the 'Factor' home page.
The icon that is displayed to indicate that the page is loading is displayed indefinitely and the 'Factor' home page does not load.

Resolution:

The 'Factor' home page is now correctly displayed.

PO07798, WorkItem:231305 - Unable to search for contacts within the contact log of an outcome plan

Issue Description:

Within an outcome plan caseworkers are able to add contacts to a Contact Log. The ability to search for contacts was inadvertently removed from the product preventing case workers from performing a search on historical contacts created within the Contact Log of an outcome plan.
User Interface Impact: Yes

Steps to Reproduce:

Login as a caseworker.
Create a new Outcome Plan for a registered person.
Navigate to the 'Admin' tab within the outcome plan.
On the 'Contact Log' page, the 'Search' tab is not visible as an inline navigation option alongside the 'All Contacts' tab.

Resolution:

The 'Search' tab has been reinstated in the application to facilitate case workers performing a search on historical contacts within the Contact Log of an outcome plan.

Provider Management

PO05826, WorkItem:144892 - Activating / deactivating a Provider Deduction affects all of the Provider's Deductions, active or inactive

Issue Description:

Activating and deactivating a provider deduction affects all of the provider's deductions, whether they are inactive or active. For example, if two in-active provider deductions exist for a given provider, activating one attempts to activate both. Likewise, if two active provider deductions exist for a provider, deactivating one attempts to deactivate both. As a result, incorrect payments are generated for providers.User Interface Impact: No

Users of CPM Provider Deductions:
Users of CPM Provider Deductions, such as Child Welfare customers, can hit this issue. A Child Welfare scenario outlining how this issue can be encountered is outlined below.

Prerequisites:

Log in as an administrator.
Go to Case > Deductions and create a new Liability Repayment applied deduction with key configuration details:
1. Prevent Overlapping = No
2. Max Deduction Percentage = 100
3. Default Percentage = 10
4. Action Type = Deduct Remaining
Go to Case > Product Delivery Case > Provider Placement > Edit Menu > Under 'Automatic Under and Overpayment Case Processing', select 'Create and Activate Payment Correction Case'.
Go to the Financial tab of Provider Placement, and select 'Add Existing' under Deductions. Add the Liability Deduction just created.
Configure a legal status that can be set for Ongoing Cases.
Log in as cpmmanager and enroll a new Provider with the following details:
1. Payment Method = Check
2. Frequency = Day 1 of every 1 month(s)
3. Provider Category = Foster Care Home
4. Provider Type = Traditional Foster Care Home
5. Physical Capacity & Designated Capacity = 4
Approve the Provider and add the service 'Traditional Foster Care' with start date as the provider enrollment date.

Steps to Reproduce:

Login as ccscaseworker, register a child (child1) and create a case of type 'Ongoing'. Add a legal status for child1 with start date the same date as the provider enrollment date.
Create a removal and placement (in the newly enrolled provider) for child1 with start date the same date as the provider enrollment date. Run the financial batches (Generate Instruction Line Items & Generate Instruments) with the first day of the following month as the processing date, and confirm that transactions were created on the Provider transaction screen.
Delete the placement created for child1 earlier; this should create a payment correction case (overpayment). To see the payment correction case, you may need to find the reference number with the financial user.
Login as cpmmanager and open the Provider.
Go to Financial > Deductions > New Applied Deduction. Select Provider Payment types as 'Provider Placement', then select the payment correction case.
Use a rate / percentage of 50, but do not activate the deduction.
Repeat steps 1 and 3 above for a second child (child2).
Set up a new applied deduction for the Provider with the payment type as ‘Provider Placement’, using a rate / percentage of 10.
Activate the second deduction, but do not activate the first.
Repeat steps 1 and 2 above for a third child (child3).
Login as cpmmanager, and open the provider. Go to the Deductions tab. Activate the first in-active deduction.
De-activate the same deduction.
Run Generate ILI & Generate Instruments with processing date as one month into the future and confirm placement payments at provider transaction screen.
Run CreateEvidencePlacement with processing date as one month into the future.
Run ReassessOutstandingCase.
Run Generate ILI & Instruments with processing date as the current date.

The active deduction will not be applied to the benefit case payment.

Resolution:

It is now possible for a resource manager to manage provider deductions independently. Where multiple deductions have been associated with a provider, the activation or de-activation of one deduction no longer causes other deductions to be incorrectly applied or not applied to payments.
Technical:

The gap in the provider deduction implementation was a missing link between provider deductions and their associated case deduction items. This has now been addressed by the addition of a new link entity, Provider Deduction CDI Link, which has been added to link provider deductions to their associated case deduction items.Note: Taking on this change requires the population of the new ProviderDeductionCDILink entity. The steps for populating this new entity are outlined in the Merative SPM Upgrade Guide in the chapter entitled 'Addition of a new link entity to link provider deductions to their associated case deduction items'.

PO07782, WorkItem:228287 - Estimated Cost is 0.00 when Service Delivery using a delivery type of 'Service Delivery with Eligibility' is first created

Issue Description:

Services can be configured to use a Delivery Type of 'Service Delivery with Eligibility', which is the delivery type used to deliver a service where eligibility for the service needs to be determined and payments in respect of the service are usually issued to a provider. When this type of configuration is used the service is associated to a product and product delivery processing is used to determine eligibility for the service. The estimated cost for the delivery of the service is calculated based upon the rate configured for the service.

When a caseworker creates a Service Delivery that uses a Delivery Type of 'Service Delivery with Eligibility' within a case, the estimated cost is not correctly calculated when the Service Delivery is initially created and remains at $0.00. If the Service Delivery is then edited and saved (with or without making any changes), the estimated cost is then calculated.
User Interface Impact: No

Steps to Reproduce:

Login as an administrator and click the 'Administration Workspace' tab.
In the Shortcuts Panel, navigate to Provider Management > Services.
From the 'Services' list page, choose a service (e.g. 'Child Care').
From the Service home page, click the 'Delivery' tab and choose the 'Edit' option.
For the delivery type choose 'Service Delivery with Eligibility'.
For Product, search for a product (e.g. 'Benefit Sample') and click 'Save'.
Login as a caseworker.
Register a person and create an integrated case.
Navigate to the 'Services' tab and create a new service delivery for the service modified above.
Click on the Service to open the Service Home page and note that the 'Estimated Cost' in the context panel is '$0.00'.
Edit the Service Delivery from the context panel action menu and click 'Save' (no changes are required); the estimated cost has been updated in the context panel.
The estimated cost is not calculated when the Service Delivery is created, it remains at $0.00. If you then edit the Service Delivery and save it again without making any changes, the estimated cost is calculated.

Resolution:

The functionality has been updated so that the estimated cost is now calculated and displayed correctly when creating the Service Delivery.

PO07777, WorkItem:229460 - Provider name is overlapping with the reference number when shortcuts menu is open

Issue Description:

Within the context panel for a provider, when the Shortcuts menu is expanded the Provider name overlaps with the reference number when too large a number of characters are used in the name. The web address and email address values also overlap with the content on the right hand side of the context panel when too large a number of characters are used for each of these.

User Interface Impact: No

Steps to Reproduce:

Login as a resource manager.
Enroll a Provider with a name with a large amount of characters.
Enter remaining mandatory information and select 'Finish'.
On the Provider home page open the Contact tab.
Add the longest allowed web address and email address ensuring to mark both as 'Primary'.
While on the Provider home page, expand the Shortcuts Panel and verify the Provider name, email and web addresses are overlapping with other elements on the page.

Resolution:

The values for the provider's name, web address and email address will now show an ellipsis in place of any substring that does not fit within the space available. This remains true if the size of the context panel changes, for example if the user expands the Shortcuts menu area.

FINANCIALS

PO06004, WorkItem:148957 - System prevents creation of new Placements (benefit payments) when closed Payment Correction (overpayment) case exists

Issue Description:

The system prevents the creation of a new placement for a provider when there is a closed Payment Correction (overpayment) case for that provider.

When a new placement is created, the system creates deductions to recoup monies on any outstanding liabilities i.e. Payment Correction cases. The error occurs because the system is checking closed Payment Correction cases, for which there are no outstanding liabilities, when attempting to create deductions.
**User Interface Impact: **No

Prerequisites:

Configure the Liability Repayment deduction to have a max deduction rate of 100 and a minimum deduction rate of 10.
Add the Liability Repayment deduction to the Provider Placement product.
Set up the placement service; the fixed rate is $10 daily.

Steps to Reproduce:

Login as a Merative SPM Resource Manager role.
Enroll the Provider and create the provider offering.
Register Test Person1 & create a placement for them.
Generate a payment.
Now cancel the placement to generate a payment correction (overpayment) for the full amount of the payment at step 4.
Register Test Person2 and create a placement for them.
Apply a deduction against the placement, specifying the percentage as 50%.
Generate the payment - half of this should get applied against the overpayment.
Register Test Person3 and create a placement for them.
Apply a deduction against the placement, specifying the percentage as 50%.
Generate the payment - half of this should get applied against the overpayment. Note: At this point the overpayment should be fully paid off.
Search for and close the Payment Correction case.
Roll the server forward.
Now set up a new placement.
Issue: An exception is thrown on the screen.

Resolution:

It is now possible to create a placement for a provider when there is a closed Payment Correction (overpayment) case for that provider. The process to determine whether to apply a deduction no longer includes checking against closed Payment Correction cases.
Technical:

Closed cases are now filtered out of the search for existing outstanding liabilities in the business process that sets up deductions for existing placement product deliveries. Once a liability is closed, there will be no outstanding amount left on it, so there is no need for it to be considered for future deductions.

WorkItem:236663 - When creating a provider deduction, the priority presented on the create screen should be taken as the lowest priority on the system for that provider + 1

Issue Description:

When creating a provider deduction for a given provider, default values are read back on the create deduction page, which includes the priority. It has been found that the priority value is taken as the lowest (i.e. the one with the highest value) priority on the entire Provider Deduction entity, plus one. It should, in fact, be the lowest priority on the Provider Deduction entity for that Provider, plus one. Even though the processing continues to work correctly, because the values are relative to each other, it is somewhat confusing when the values are presented to a case worker.
User Interface Impact: No

Steps to Reproduce: The following are high level steps of how this issue manifests itself:

Create an ongoing child welfare case for Child A and place them in Provider A.
Create a second ongoing child welfare case for Child B and place them in Provider A.
Create a third ongoing child welfare case for Child C and place them in Provider A.
Create an ongoing child welfare case for Child D and place them in Provider B.
Create a second ongoing child welfare case for Child E and place them in Provider B.
Create a third ongoing child welfare case for Child F and place them in Provider B.
Generate the payments for all of these placements.
Now cancel the placement for Child C in Provider A; this will generate a liability.
Also cancel the placement for Child F in Provider B; this will generate a liability.
Now set up Provider Deductions for Provider A so that their liability can be recouped.
1. The default values presented for the first Provider Deduction for Provider A will be have the priority set to 1.
2. The default values presented for the second Provider Deduction for Provider A will be have the priority set to 2.
Now set up Provider Deductions for Provider B so that their liability can be recouped.
The default values presented for the first Provider Deduction for Provider B will be have the priority set to 3.
The default values presented for the second Provider Deduction for Provider B will be have the priority set to 4.

**Note: **The default values presented for the Provider Deductions for Provider B should be 1 and 2.

Resolution:

The API that retrieves the default values for the create provider deduction page has been updated to return the lowest priority on the Provider Deduction entity for that specific Provider, plus one. It's important to note that no historical deductions will be affected or will need to be updated.

Supervisor Workspace

PO07217, WorkItem:198952 - Supervisor search results for cases to be reassigned are not displayed correctly

Issue Description:

Previously when the Supervisor opened the Caseworker’s workspace and selected to reassign cases from the Caseworker to a different user, the search result was not presenting the correct list of cases. Where the number of cases assigned to the Caseworker exceeded the value set in curam.db.readmultimax, a list of size equal to this value was returned, but once these were reassigned subsequent searches did not return the remaining list of cases to be reassigned.

User Interface Changed: No

Pre-requisite: In the below scenario a supervisor intends to reassign all of the cases assigned to the caseworker.

Login as sysadmin.
Navigate to System Configurations.
Navigate to Shortcuts menu.
Navigate to Application Data, Property Administration.
Search for curam.batch.bulkcasereassignment.deferredprocess.max.processing.count.
Edit the property and change the value to 2.
Search for curam.db.readmultimax.
Edit the property and update the value to 5.
Click on Publish changes.
Login as caseworker.
Search for a person (for example James Smith).
Create 6 cases for this person.

Steps to reproduce

Login as a supervisor.
Navigate to the Team and Workloads application tab.
Select My Users.
Select the caseworker user.
View the Cases option from the navigation bar.
Click Reassign Cases, which will open up a reassign modal.
Select a new owner to assign the cases to.
Select the 'List all cases assigned to user' checkbox.
Click search.
The search will return 5 results as per the curam.db.readmultimax parameter.
Reassign the 5 records displayed, which will be added to the bulk case reassignment batch queue.
Repeat steps 6 to 9
No further cases are displayed, the 6th case assigned to the caseworker is not listed and therefore cannot be reassigned.

Resolution:

This issue has been resolved by updating the query which retrieves the cases to be reassigned to correctly consider bulk case reassignment requests. This query now takes into account the cases that have already been reassigned, and the correct number of outstanding available cases is now displayed in the search results.

Universal Access

PO06895, WorkItem:186435 - UHSE occurs on the Save Information page of an external online application

Issue Description:

Previously, when a user clicked Next on the 'Save Information' page on an external application without choosing the Save or Quit option, and then subsequently choose the Quit option and clicked Next, a unhandled server exception occurred.
User Interface Impact: Yes

Steps to Reproduce:

Login in as external user.
Start an application.
Navigate to the Other Household Members page and answer the question "No".
Click Save and Exit button. The 'Save Information?' page is displayed.
Click Next without selecting either option. A validation message is displayed.
Select the "Quit" option and application proceeds to the home page.

Resolution:

The issue has now been resolved by updating the xml file on this page.

WorkItem:193323 - Tablet Accessibility: Unable to select mega menu items

Issue Description:

Previously, when using an iPad there was an issue with the help menu in Universal Access when VoiceOver was enabled. After opening the help menu (by selecting the (?) icon in the Universal Access banner menu) a user was unable to navigate through and select an item in the help menu while using a keyboard.
User Interface Impact: No

Steps to Reproduce:

Open up the Merative Social Program Management Universal Access Home page on an iPad device with a keyboard connected.
Enable VoiceOver.
With the VoiceOver key held down, navigate focus to the help menu icon (?) using the left and right arrow keys.
Double tap the screen or hit enter on the keyboard to open the help menu.

Resolution:

This issue has since been resolved. With VoiceOver enabled on an iPad, VoiceOver focus automatically switch to the first menu item in the help menu when the help menu is opened. This allows the user to navigate through items in the help menu and select a value.

PO07697, WorkItem:225585 - Setting X-Content-Type-Options to 'nosniff' causes issues in Universal Access Portal

Issue Description:

On setting the 'X-Content-Type-Options' to 'nosniff' in Merative HTTP Server (via http.conf file), the mandatory field indicator displays 'Mandatory' instead of an asterisk (*) on the Citizen Portal input pages.
User Interface Impact: Yes

Steps to Reproduce:

Set X-Content-Type-Options to 'nosniff' in http.conf file.
Login to the Citizen Portal.
Start an application.
Note the mandatory fields on the input page.

Resolution:

This issue is now resolved and the mandatory fields now display an asterisk (*) instead of 'Mandatory'.

WorkItem:240711 - Rest API documentation pages are not being generated by Swagger<br/>

Issue Description:

The Rest APIs documentation pages are not being generated by Swagger. An error is thrown during the validation phase of Swagger's build.
**User Interface Impact: **No

Steps to Reproduce:

Access the APIs documentation URL: "/Rest/api/definitions/v1"
An error message is displayed.

Resolution:

All the Rest APIs documentation are now being properly generated.

WorkItem:240713 - Intake Applications - Rest API - Change IntakeApplicationFormAPI.getFormDetails method to return all fields

Issue Description

In certain scenarios the value of submitOnCompletionInd for an IntakeApplicationType was being ignored. This meant that when clicking "Save and Exit" during a script the user would see the popup allowing them to make a partial submission, which should not appear if submitOnCompletionInd is true.

User Interface Impact : Yes. A popup was appearing where it should not.

Steps to Reproduce

Log in as jamessmith
Start an application that has submitOnCompletionInd set to true (e.g. Rent Subsidy)
Click "Save & Exit" during the script
Choose to save the application
Verify we are returned to the dashboard
Resume the newly-saved application
Click "Save & Exit" button

Resolution

The application now respects the value of submitOnCompletionInd and displays.

Appeals

PO07257, WorkItem:200418 - Closing legal action generates unwanted error mails and error messages in the logs

Issue Description

Previously, closing a Legal Action caused unhandled exceptions to appear in the logs and generated unwanted error emails. This was due to CloseCase deferred process not functioning correctly for a Legal Action case type. In the method CloseCase.closeAssociatedRecords, the logic to regenerate financials was always attempted but since legal action cases do not have financials, this resulted in an unhandled exception.
User Interface Impact: No

Steps to Reproduce

Login as ccscaseworker.
Create an ongoing case with a few persons.
Create an external party (court) with Person (judge).
Make a Petition and a legal petition available for ongoing cases.
Create legal action using the court and judge and the case persons.
Close the legal action using for example 'Other' as reason and a comment.
Look in the curamapplog for the exception.

Resolution

This issue has now been resolved, CloseCase deferred process functions correctly for Legal Action case type. This was achieved by preventing CloseCase.closeAssociatedRecords from regenerating financials for case types that do not have them. It will now regenerate financials for product delivery and liability case types only.

Intelligent Evidence Gathering

PO06595 , WorkItem:173224 - Unknown user displayed in the household income page of an application

Issue Description:

Unknown user displayed in the IEG script when a user has deleted a person from the household on the summary page and then navigated back using navigation panel to Income page in the script.

This is due to the Intelligent Evidence Gathering engine not updating the list of visited pages correctly after an entity has been deleted.
User Interface Impact: No

Steps to Reproduce:

Log in to the Merative SPM application as hcrcaseworker.
Register an adult person and create a new application.
Fill out the details for the primary person.
Add an adult spouse to the household and fill out the details for that person.
Add income for both household members.
Arrive at the summary page.
Remove the spouse from the household.
Click on the "Household Income" section in the navigational panel. Notice a tab is displayed for an unknown person.

Note: If you are a customer that does not use the Healthcare Reform Solution, but have configured Intelligence Evidence Gathering scripts as an Intake mechanism, you can reproduce this scenario by configuring a script which allows a user to enter and delete a top-level entity, such as a Person entity, a child entity, such as an Income entity, and which also contains a page which references both those entity types.
Non-Healthcare Reform Steps to Reproduce:

Open the configured script.
Fill out all details for primary person and spouse.
Create an income for each person.
For each person, navigate through the page which references both entity types.
Using the navigational panel, go to the section where you can delete a person and delete the last person who was entered.
Using the navigational panel, go back to the section which contains the page which references both entity types.

Resolution:

The issue has been resolved. Now after deleting the Person from the script the pages that reference a Person entity and child entity are updated accordingly.

PO07802, WorkItem:231314 - Pressing the keyboard 'Enter' key on a combobox with an inline autocomplete suggestion results in a validation error being thrown

Issue Description:

Previously, when navigating an Intelligence Evidence Gathering page using the keyboard only and hitting the enter key on a combobox with an inline autocomplete suggestion, resulted in the page performing the default action and navigating to the next page. This resulted in a validation being thrown if some mandatory fields were not completed.
User Interface Impact: Yes
Steps to Reproduce:

Log into as a caseworker.
Register a person and start a new Application.
Navigate using the keyboard to a combobox input.
Type the initial letter for a suggested answer in the dropdown.
Press the enter key to populate the combobox with the autocomplete suggested value.
The cursor should appear at the end of the text in the combobox.

Resolution:

The IEG page has been updated to properly handle the enter key on the combobox to select the autocomplete suggestion.

PO07815, WorkItem:231716 - Ghost person is being displayed and an application error occurs when a person is removed from HCR application

Issue Description:

An issue exists where an application error can appear while navigating through an Intelligent Evidence Gathering script after an entity has been deleted due to the Intelligent Evidence Gathering engine not updating the list of visited pages correctly.
User Interface Impact: No

Steps to Reproduce:

Log in to the Merative SPM application as hcrcaseworker.
Register an adult person and create a new application.
Navigate through the script, filling out the details for the primary person.
Add an adult spouse to the household and fill out the details for that person.
Ensure both household members want to help pay for their own health insurance and benefits.
Ensure both household members have income and are tax filers.
Ensure the spouse plans to file a joint tax return with the primary person
When asked does the household member pay for certain things that can be deducted on an income tax return, leave the question unanswered.
Navigate to the "Additional Household Information" page and don't select anything.
Click on the "Household Information" section in the navigational panel.
Remove the spouse from the household.
Click on the "Household Income" section in the navigational panel. Notice a tab is displayed for an unregistered person.
Select "Yes" for the expected annual income question and click "Next".
On the "Additional Household Information" page, click on the "Household Information" section in the navigational panel.

Note:

If you are a customer that does not use the Healthcare Reform Solution, but have configured Intelligence Evidence Gathering scripts as an Intake mechanism, you can reproduce this scenario by configuring a script which allows a user to enter and delete a top-level entity, such as a Person entity, a child entity, such as an Income entity, and which also contains a page which references both those entity types.

To do this, create a script with a Question Page and Summary Page element which allows a user to create and delete multiple Person entities and a Question Page element which allows a user to enter an Income entity for each person. Then construct a Loop element whose loop type is set to "for-each" and whose entity type is set to Person. Within the Loop element, configure a Question Page element with an entity type set to be the same as the Loop entity type. A Question element within a Cluster element, whose entity type is set to Income, should then be constructed on the Question page.

Non-Healthcare Reform Steps to Reproduce:

Open the configured script.
Create a primary person and two additional people.
Create an income for each person.
For each person, navigate through the page which references both entity types.
Using the navigational panel, go to the section where you can delete a person and delete the last person who was entered.
Using the navigational panel, go back to the section which contains the page which references both entity types.

Resolution:

An application error will no longer appear while navigating through an Intelligent Evidence Gathering script after deleting an entity due to the Intelligent Evidence Gathering engine clearing the list of visited pages correctly.

PO07869, WorkItem:234789 - Outcome plan assessment back button navigation does not return to the previous page as expected

Issue Description:

An issue occurs in Intelligent Evidence Gathering scripts where navigating using the back button does not return to the previous page as expected. This issue occurs when there are one or more pages, whose entity type has been specified to one that was created outside of an Intelligent Evidence Gathering script, for example via a Callout element, but is not referenced by any Question or Cluster elements elsewhere in the script, and where all of the Cluster elements inside those pages have their entity type set to another entity type.

User Interface Impact: No

Steps to Reproduce:

Configure an Intelligent Evidence Gathering script that contains a question page, a summary page and a final landing page, ensuring all pages contain a navigational back button. Configure a Callout element to create an entity of a certain type before the first question page, and set the entity type of the first question page and the following summary page to the same entity type that was created by the Callout. Then configure a Cluster element, which contains a Question element, inside both the question and summary pages, and set the entity type of the Cluster element to be different to the entity type of the page.

Navigate to the first question page and answer any questions that are present.
Navigate through the script until you get to the final landing page.
Click the back button to go to the final summary page.
Click the back button again and you will arrive on the final landing page again.
Click the back button again and you will arrive on the final question page.

Resolution:

This issue has now been fixed, and users navigating using the back button will return to the previous page as expected.

WorkItem:240633 - IEG input sanitizing: stripping tags and keeping non-ascii characters

Issue Description:

Previously, when a user entered text into the Merative Social Program Management Universal Access Responsive Web Application, it was not sanitized before it was saved. For example, “Cúram” was transformed to "C&#250ram”. As a result, the text was unreadable for languages based on non-ASCII characters
**User Interface Impact: **YES, HTML Tags are removed.

Steps to Reproduce:

Navigate to a form in Merative Social Program Management Universal Access Responsive Web Application
Enter a non-ASCII character, i.e “Cúram”, into the form.
Save the form and view the details on the summary page.
Note that non-ASCII characters are unreadable, i.e "C&#250ram”

Resolution:

Now, the sanitization mechanism removes the HTML tags only and non-ASCII characters are readable

Evidence Broker

PO07654, WorkItem:223602 - Exception occurs while trying to broker evidence from a person case to an integrated case by using the old evidence broker in V7.0.2

Issue Description:

While trying to broker evidence from a person case to an integrated case by using an old evidence broker configuration, an unhandled server exception occurs when the user clicks the Incoming Evidence tab.
User Interface Impact: Yes

Steps to Reproduce:

Log on as sysadmin.
Set the value of the "curam.aes.advancedEvidenceSharingEnabled" property to "NO" and publish the changes.
Log on as hcrcaseworker.
Submit a simple application with a single member with income in the Streamline Medicaid range. Provide the date of birth as 1/1/1980.
Open the application case Action menu and click Authorize. An integrated case and product delivery case are created.
At the person level, click Evidence in the shortcuts panel, then edit the Birth and Death Details evidence.
Modify the date of birth to 1/1/1982.
Click Save.
Open the integrated case, then click the Evidence > Incoming Evidence tab. An unhandled server exception message is displayed.

Resolution:

The old evidence broker was deprecated in V7.0.2 and and is disabled by default in the application. To enable the old evidence broker, extra configuration is required in addition to configuring the "curam.aes.advancedEvidenceSharingEnabled" property. The unhandled server exception occurred because the system was reverted back to use the old broker without changing the UI configuration to use the old Incoming Evidence UI, it was trying to use the new Incoming Evidence UI.

All configuration steps are now described in the "Enabling Evidence Broker 1" section in the Upgrade Helper Guide. For more information, see

https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

PO07891, WorkItem:236110 - 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.

Change the client machine's timezone to EST, e.g. New York.
In Admin; check to ensure there is no identical sharing configuration setup for Social Assistance - Email > Social Assistance - Email.
Register a person.
Create a Social Assistance case for that person (Case 1).
Add email evidence with a start date of yesterday & apply changes.
Create another Social Assistance case for that person (Case 2).
Login to Admin and now add identical sharing configuration of Social Assistance - Email > Social Assistance - Email.
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.
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.
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

../Curam/components/AdvancedEvidenceSharing/WebContent/
CDEJ/jscript/aes/BusinessObjectViewer.js

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

Financial Management

PO04061, WorkItem:103256 - System does not allow creation of a deduction when there is an active deduction with the same name and overlapping dates

Issue Description:

The system prevented the creation of a deduction when an active deduction with the same name and overlapping dates existed on the system for the same case. This occurred despite the 'prevent overlapping' flag being set to false for the underlying product.

User Interface Impact: No

Steps to Reproduce:

Set up a Liability Repayment deduction on a product with the prevent overlapping flag set to false.
Set up a product delivery to deliver this product and generate payments on it.
Modify the evidence to create an over-payment.
Create a deduction on the product delivery to offset the over-payment, but don't activate it.
Create a second deduction on the product delivery to offset the over-payment, but don't activate it.
Activate the first deduction.
Activate the second deduction.
Create a third deduction against the over-payment with dates which overlap with one or other of the first two deductions - an error is reported to the case worker preventing them from creating the deduction due to an existing overlapping deduction.

Resolution:

The process for setting up a deduction was treating an informational as an error, which prevented a caseworker from completing the set-up steps. It is now possible to create multiple overlapping deductions with the same name when the 'prevent overlapping' flag is set to false for the underlying product.

Technical:

The issue was caused by a call to the Informational Manager failOperation API when it contained a warning, when it should only be called when the type of informational contained within the Informational Manager is of type 'Error' or 'Fatal Error'. Warnings should not prevent the transaction from completing, instead the warning should be returned as an informational, which can be achieved by wrapping the call to the failOperation in an API that checks explicitly for these types.

The fix for the reported issue introduces an API to wrap the call to failOperation and performs an explicit check for informationals of type 'Error' and 'Fatal Error'.

It is now possible to create multiple overlapping deductions with the same name when the 'prevent overlapping' flag is set to false for the underlying product.

Identity Intelligence

WorkItem:232534 - Merative SPM is now certified to use IBM InfoSphere Identity Insight 9.0.0

The IBM InfoSphere Identity Insight (II) product analyzes participant data that is collected from the Merative SPM system. The product checks if similar or suspicious identities exist in the participant data. An analysis takes place to indicate a risk of fraud, waste, or abuse when a caseworker enters or works with one candidate.

The version of the IBM InfoSphere Identity Insight product certified for usage with SPM has been updated from 8 to 9.0.0. There were a number of changes made as part of the II version update.

1. Identity Insight's authentication framework has been standardized to take advantage of the many authentication options provided by WebSphere Liberty. As a result of this the following is required to connect to the II service:

a user name must be specified
a password must be specified.

To allow the user name and password to be configured by customers, the following dynamic application properties have been introduced which allows the user name and password to be used for InfoShere Insight integration to be set and changed as required.

curam.programIntegrity.II.username
curam.programIntegrity.II.password

2. Merative Social Program Management uses web services to connect to the Identity Insights instance to pass data to that services and retrieve the results. These web services are delivered as part of an II installation and the associated WSDL files must be taken onto SPM (EJBServer\components\ProgramIntegrity\wsdl) and the relevant web services stubs generated from them.
The following two II WSDL files have been updated and the associated web services regenerated to ensure compatibility with the new version of II:

EntityResolver.wsdl
srd.wsdl

Solutions

Income Support

PO03820, WorkItem:101352 - Incorrect Paid Employment Period Start Date

Issue Description:

When Paid Employment evidence is created on an Income Support integrated case, it is not possible to capture a business start date for the evidence. Because of this, the start date of the case is displayed as the start date for the period for the evidence on the Evidence list pages. This can result in the display of misleading information for the caseworker when the start date of the employment associated to the Paid Employment evidence is not the same as the case start date.

User Interface Impact: No

Steps to reproduce:

Login as an Income Support caseworker.
Register a new person.
Create a new Employment record for the person, with a start date in the past.
Create a new Income Support integrated case for the person.
Add Paid Employment evidence to the case to reflect the person's employment.
The Evidence list pages show the period for the Paid Employment evidence to be from the integrated case start date forward, even though the Employment started in the past.

Resolution:

It is now possible for a different start date to be displayed for the period for the Paid Employment evidence, so that the start date of the related Employment record can be used.

Technical:

A new hook point, EvidencePeriodHook, has been added to the evidence infrastructure to allow customers to override, at an evidence type level, the business start and end dates used for the period on the Evidence list pages. The hook point was added as part of WorkItem: 123096. An implementation of this hook can be provided for the Paid Employment evidence type to allow for the return of the associated Employment start and end dates. The custom implementation will then need to be bound to the evidence type.

PO06440, WorkItem:166062 - Outstanding verification cannot be created for Contributor Evidence configured at PD level

Issue Description:

A mandatory verification on the Expense Amount attribute of the Contributor evidence configured at the product delivery level does not get created.

Setting of the verification at the product delivery level is dependent on a case participant being present in the evidence hierarchy, as the logic reads back up through the hierarchy as far as it can to find a case participant attribute. If it finds none, then there is no value available for creating the product delivery verification.

User Interface Impact: No

Steps to Reproduce:

Login as an administrator.
Enable mandatory verifications for the product delivery, for example for Food Assistance, Cash Assistance, or Medical Assistance.
Configure verifications for evidence, for example for Contributor.
Login as an Income Support caseworker, and submit an application for a parent and child who are determined eligible for the product delivery configured above.
Create the evidence configured above.
Check the Verifications tab on the product delivery and see that the mandatory outstanding verifications are not created for the evidence.

Resolution:

Now, a mandatory verification on the Expense Amount attribute of the Contributor evidence configured at the product delivery level is created.

Technical:

A fallback mechanism has been incorporated into the static evidence generator for structures where no case participant exists. In this instance, a case participant associated with the evidence descriptor is used instead to guarantee that the product delivery verification gets created. The issue has been addressed by an update to the static evidence generator. This was addressed in WorkItem: 234258.

WorkItem:185477 - When a new member is added to an Income Support application using the 'Add a Member' Guided Change wizard, the user is incorrectly navigated to an integrated case

Issue Description:

A caseworker can add a new member to the household within an Income Support application using the 'Add a Member' guided change wizard. When the caseworker completes the 'Add a Member' wizard, the caseworker is incorrectly navigated to the Guided Change page within an Income Support integrated case, rather than to the Guided Change page within the Income Support application.

User Interface Impact: Yes

Steps to Reproduce:

Login as an Income Support caseworker.
Create an Income Support application.
Add a new member to the application by selecting the Guided Change > Add a Member action item from the tab level action menu.
Complete the 'Add a Member' wizard.
A new tab for an Income Support integrated case is incorrectly opened and the user is navigated to the Guided Change page within the integrated case.

Resolution:

When the caseworker adds a new member to an Income Support application using the 'Add a Member' guided change wizard, the caseworker is now correctly navigated to the Guided Change page within the Income Support application.

Technical:

The out-of-the-box summary page for the 'Add a Member' Guided Change wizard is ISAddMemberWizard_summaryDetails. This previously redirected the user to the CREOLEIntegratedCase_listGuidedChange page, which is associated with the Income Support IC tab. The logic has been updated to determine, on submission, where the Guided Change began and redirect appropriately. The functionality now redirects to either

CREOLEIntegratedCase_listGuidedChange (for integrated cases) or
ISPApplication_listGuidedChange (for application cases)

WorkItem:222596 - Removal of Concurrent Eligibility 7.0.3 Refresh Pack Application Properties

Issue Description:

Previously the feature that detects concurrent eligibility for Food Assistance and Cash Assistance was configurable through application properties and was turned off by default to support its initial release in the 7.0.3 refresh pack.

Two additional application properties were also available to control whether validations related to program authorization should occur or not and were also turned off by default.

User Interface Impact: No
Steps to Reproduce: N/A
Resolution:

The following application properties have now been removed as they were only intended for refresh pack purposes:

Dual Detection Enabled Indicator for Cash Assistance
- curam.isproduct.cashassistance.dualdetection.enabled
- Determines whether Cash Assistance rules check for concurrent eligibility when determining client eligibility. When the value is 'YES', concurrent eligibility is checked.
Dual Detection Enabled Indicator for Food Assistance
- curam.isproduct.foodassistance.dualdetection.enabled
- Determines whether Food Assistance rules check for concurrent eligibility when determining client eligibility. When the value is 'YES', concurrent eligibility is checked.
Override the authorization validation for end-dated members
- curam.isproduct.dualparticipant.enddatedhhmember.authoverride.
  enabled
- When Food Assistance or Cash Assistance is authorized, determines whether the authorization should be allowed when an applicant is a case member on another case of the same type that does not have a status of closed but has left the household. When the value is 'YES', the system overrides the authorization validation and authorization is allowed.
Override Food Assistance authorization validation for member living in a domestic violence situation
curam.isproduct.foodassistance.dvauthoverride.enabled
When Food Assistance is authorized, determines whether the authorization should be allowed when an applicant is a case member on another Food Assistance case that does not have a status of closed, but has living arrangement evidence of type 'Shelter for Battered Women and Children' on the new application. When the value is 'YES', the system overrides the authorization validation and authorization is allowed.

The following guide that references the configuration options has also now been updated:

Configuring concurrent eligibility detection in the Configuring Income Support section.

link:

https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

PO07740, WorkItem:227613 - Helper text pop up message displays 'null' or blank text

Issue Description:

Four questions from the case management intake script are missing their corresponding help-texts.

User Interface Impact: Yes

Steps to Reproduce:

Login as an Insurance Affordability caseworker and start a new application.
Navigate to pages where the following questions are asked and click on the help icon for the following questions.
1. 'Do you have a fixed address?'
2. 'Is the mailing address the same as home address?'
3. 'Does <participant> have an SSN?'
4. 'Does this person want to find out if they can get help paying for their own health insurance and health benefits?'
Help text is not displayed for these questions.

Resolution:

The missing help-texts have been added to the IEG script XML files and to the corresponding properties files.

WorkItem:228872 - Add a Member Guided Change wizard is not correctly saving primary caretaker information entered in the Relationship Details page

Issue Description:

When adding a member to a household using the 'Add a Member' guided change wizard on an Income Support case, the caseworker can select a Primary Caretaker indicator on the Relationship Details page to indicate that the new member being added is the primary caretaker of an existing household member as part of establishing a relationship between the two members. When the caseworkers selects the Primary Caretaker indicator and completes the 'Add a Member' wizard the information is not saved to the Household Relationship evidence that is created at the end of the process.

**User Interface Impact: **No.

Steps to Reproduce:

Login as an Income Support caseworker.
Create an Income Support integrated case.
Add a new member to the household by selecting the Guided Change > Add a Member action item from the tab level action menu.
On the Relationship Details page, indicate that the new member is the primary caretaker of an existing household member.
Complete the wizard.
Navigate to the Evidence Workspace and view the Household Relationship evidence that was created.
The 'Primary Caretaker' indicator is not set to 'Yes'.

Resolution:

The 'Primary Caretaker' indicator is now correctly populated when the Household Relationship evidence is created.

PO07893, WorkItem:236133 - Dual Eligibility Report batch process fails when run on a different deployed machine

Issue Description:

When the application is built and deployed on different locations (e.g. built on server A in C: drive and deployed on server B in D: drive), running the Dual Eligibility Report batch process may fail.

**User Interface Impact: **No
Steps to Reproduce:

Build EJBServer
Deploy to Server with different path
Run the Dual Eligibility Report

Resolution:

The issues occurs because the report uses CER Generated Rule Classes to reference CashAssistanceRuleSet.CADualDetectionCalculator and FoodAssistanceRuleSet.FADualDetectionCalculator. The generated classes are intended only for use by test code and are not supported in production.

An implementable interface has been removed as part of this change as it exposed the generated rule classes in the contract, and has instead been replaced with a compliant approach.

Removed: curam.isproduct.creole.dualdetection.batch.report.dualeligibility.impl.
DualDetectionCalculatorFactory
Replaced with: curam.isproduct.creole.dualdetection.batch.report.dualeligibility.impl.
DualDetectionCalculator

The batch report is intended only as an admin tool for understanding existing cases of Dual Eligibility. Where custom implementations have been provided for DualDetectionCalculatorFactory the following should be noted:

The implementation will fail to compile now that the interface DualDetectionCalculatorFactory has been removed
A new implementation should be made implementing the DualDetectionCalculator interface
The new implementation must be bound to the Product type code in place of the existing DualDetectionCalculatorFactory binding. This will ensure the report runs for any custom products the DualDetectionCalculator has been implemented for.

PO07948, WorkItem:238564 - Error occurs when selecting the 'Open in New Tab' function on the Verifications page

Issue Description:

On an Income Support integrated case, clicking on the 'Open in New Tab' page level action on the evidence Verifications page throws an error.

User Interface Impact: Yes, the 'Open in New Tab' page level action menu is removed from the evidence Verifications page for Income Support.

Steps to Reproduce:

Login as an Income Support caseworker.
Register a person and create an application for Food Assistance
Authorize the application.
Navigate to the Income Support integrated case.
Navigate to the Verifications page under the Evidence tab.
Select the 'Open in New Tab' function on the page.
The following error message is displayed: "ERROR: The page that you are trying to link to is associated with multiple tabs: [CaseEvidence,OutcomePlan]. Therefore the tab to open cannot be determined and the page will open in the current."

Resolution:

The 'Open in New Tab' page level function has been removed from the Verifications page. This was done to ensure consistency between the Insurance Affordability and Income Support integrated cases.

ASSESSMENT AND TRACKING RETURN TO WORK

PO06394, WorkItem:163194 - Unhandled server exception occurs when viewing the Outcome Plan Home page of an outcome plan that includes a new action with no frequency specified

Issue Description:

As part of the Return to Work Outcome Management process in Income Support, clients that are work registered can be referred to a provider and an outcome plan can then be created within the Income Support integrated case to help clients attain self sufficiency. When an outcome plan is created as part of this process, if a user manually adds a new action to the outcome plan and does not specify a frequency for the action, an unhandled server exception occurs when the user attempts to view the Outcome Plan Home page.

User Interface Impact: No

Steps to Reproduce:

Login as a system administrator and enable geocoding functionality for the Work Referral process.
1. Set the curam.miscapp.geocode.enabled application property to 'YES'.
2. Set the miscapp.geocode.googlemapsapikey application property to the appropriate Google API Key.
Ensure that the address for a provider and the address entered for a client during the application process will result in a match during the Work Referral process.
Login as an Income Support caseworker.
Create and submit a new application for Cash Assistance for a mother and child that includes work registration and other evidence and that will result in an eligible determination.
Check eligibility for Cash Assistance to ensure that the determination result is 'Eligible'.
Navigate to the Work Eligibility tab and create a new Referral for the mother.
Authorize the application.
Login as a user that manages the creation of return to work outcome plans.
Navigate to the Pending Referrals tab under the Outcome Plans section of the Shortcuts menu.
Search for the referral created for the mother, and assign the referral to the user.
Navigate to the Income Support integrated case created for the mother.
Create a new outcome plan of type 'Self Sufficiency Outcome Plan'.
Within the outcome plan, navigate to the Activities tab and select to create a new action.
In step 1 of the New Action wizard, do not select any of the pre-defined actions and instead enter a name for a new action.
In step 3 of the wizard, leave the Frequency field blank.
Finish the wizard and save the new action.
Navigate to the Outcome Plan Home page.
An unhandled server exception occurs.

Resolution:

The Outcome Plan Home page has been updated to correctly recognize manually entered actions that have no frequency and displays correctly.

Technical Details:

The error occurred in the following rules during a call-out to a Statics class:

Rules (unmodified):
- /EJBServer/components/AssessmentTracking/CREOLE_Rule_Sets/
  Data/OutcomePlan/ActivityDetails.xml, Attribute scheduledMinutesTimeLine
Static method (modified):
curam.assessmenttracking.impl.Statics.determineScheduledTimeLine

The Static method has been updated to return the default zero forever Timeline where no frequency is specified.

FOOD ASSISTANCE

PO06147, WorkItem:152703 - Unhandled Server Exception occurs when editing Household Relationship evidence for a reciprocal relationship

Issue Description:

When a caseworker creates Household Relationship evidence on an Income Support integrated case, reciprocal relationships are automatically created. For example, if a boy and a girl are household members of a case and Household Relationship evidence is added for the boy that indicates that the girl is the sister of the boy, the system automatically creates a reciprocal relationship that indicates that the boy is the brother of the girl.

If a caseworker subsequently attempts to modify the reciprocal Household Relationship evidence record that was created by the system, an unhandled server exception occurs.

User Interface Impact: No

Steps to Reproduce:

Login as an Income Support caseworker.
Register a person.
From the Applications tab of the person record, select 'New Application'.
Complete an application for Food Assistance that includes two applicants and submit the application. Be sure to tick the checkbox for 'Does this person purchase and prepare food with the claimant?'.
Navigate to the application case and add the required evidence to make the household eligible.
Resolve any outstanding verifications.
Authorize the case and activate the Food Assistance product delivery case.
Navigate to the Income Support integrated case and edit the 'Household Relationship' evidence record that was created by the system as a reciprocal record for the one entered by the caseworker; specifically change the value of the 'Relationship Type' from the drop-down menu.
Click Save.
An unhandled server exception occurs.

Resolution:

This issue has been addressed and it is now possible to successfully modify a Household Relationship evidence record the represents a reciprocal relationship.

MEDICAL ASSISTANCE

WorkItem:103814 - Implementation for the @ProfileMethod annotation for verification services should only print to the system logs when tracing turned on

Issue Description:

The verification services inside Insurance Affordability are annotated with @ProfileMethod. The interceptor implementation of this annotation reported everything to the system logs, regardless of whether tracing was turned on or not. This has the side effect of polluting the logs and making them difficult to interrogate. It also reduces the scalability of the system.

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Submit the application.
An examination of the system logs will show that it will contain logging information for the verification services that are called.

Resolution:

The implementation associated with the @ProfileMethod annotation in Insurance Affordability for the verification services has been updated to only write to the system logs when the tracing is turned on. Nothing is written to the logs when tracing is turned off. Additionally, the JMX infrastructure is used to capture the performance stats associated with the verification services.

PO04427, WorkItem:104951 - Incorrectly allowing multiple overlapping Tax Relationship records to be created

Issue Description:

Tax Relationship evidence is used to indicate when one person is considered a tax dependent of another person. If a Tax Relationship is created between a child and one of their parents on an Insurance Affordability integrated case, there is no validation to prevent another Tax Relationship being set up for the child and their other parent for the same period of time. This allows a caseworker to incorrectly indicate that a child is being claimed by different parents for the same time period.
User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for 2 parents and a child.
Indicate that the child is a tax dependent of the father so that a Tax Relationship evidence record is created.
Submit and authorize application.
Create a new Tax Relationship evidence record for the child and the mother.
The system does not prevent the new overlapping Tax Relationship record from being created.

Resolution:

The system now checks against existing Tax Relationship records for the dependent in question. If any exist for the given date range, a validation is thrown.
Technical:

The validation has been added to the HCRTaxRelationShipValidatorRuleset.xml rule-set.

PO05283, WorkItem:105328 - Validation prevents multiple non-overlapping Incarceration records for a participant

Issue Description:

Caseworkers are unable to create multiple non-overlapping Incarceration evidence records for a given participant. This makes it difficult for a caseworker to properly capture incarceration history for somebody who is in and out of correctional facilities throughout the lifecycle of the case.

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Submit and authorize application.
Create a new Incarceration evidence record for a 2 month time-frame.
Create a second Incarceration evidence record which does not overlap with the first one.
The second Incarceration record cannot be created due to the validation 'An Incarceration record already exists for this Participant'.

Resolution:

The meta-data for the Incarceration dynamic evidence type has been corrected, and multiple non-overlapping Incarceration evidence records can now be added for a participant on an Insurance Affordability integrated case.
Technical:

The meta-data file that has been fixed is Metadata_HCRIncarceration_20150811.xml.

PO05547, PO06189, WorkItem:105444 - Un-handled server exception occurs when creating/editing evidence and no participant is selected

Issue Description:

Creating or editing evidence on an Insurance Affordability integrated case results in an un-handled server exception if no participant is selected.
User Interface Impact: Yes

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Submit and authorize application.
Create or edit evidence (e.g. pregnancy/member relationship/Income/Benefit) with blank case participant.
An un-handled server exception occurs.

Resolution:

The following corrections have been made to the latest version of dynamic evidence:
a) Case Participant marked as mandatory
b) Case Participant defaulted to blank

a) Case Participant marked as mandatory
The Case Participant drop-down field has been marked as mandatory. In instances where 'All Panels' has been specified in the meta-data, i.e. a Case Participant can be selected in a drop-down, a participant can be searched for, or a new participant created, it is not possible to mark the drop-down as mandatory.

b) Case Participant defaulted to blank
For those fields where the Case Participant has been marked as mandatory, the behaviour of the drop-down has been updated to default the field to blank. This means that the caseworker must select the correct case participant before saving the record. If the ‘Case Participant’ field is left blank, a validation is displayed ‘Case Participant must be entered’.

When a dynamic evidence types is created for a case participant, the case participant field appears as read-only on the modify screen.

These changes to case participant have been implemented across all dynamic evidence that allow a case participant to be selected when creating an evidence record through the user interface. For details of these changes see WorkItem 237075.

PO07319, WorkItem:164031 - Duplicate private address evidence created when adding a person to a case using the change of circumstance process or Add a Member guided change wizard

Issue Description:

Duplicate private address evidence is being created when a person is added to an Insurance Affordability integrated case via the change of circumstance process or the Add a Member guided change wizard.
User Interface Impact: No

Steps to Reproduce:

Submit an application via the Citizen Portal for a husband & wife who both reside at the same address. Select the mailing address to be the same as the private address.
Verify that three address evidence records are created on the Application Case and Insurance Affordability integrated case. Two address evidence records for the husband (private & mailing) and one for the wife (mailing).
Add a child to the integrated case using the change of circumstance process. Select that the child resides with the husband and wife created in first step.
Submit the change of circumstance.
An inspection of the evidence will show that duplicate address records have been created for the child.

Resolution:

When a person is added to an Insurance Affordability integrated case via the change of circumstance process or the Add a Member guided change wizard, only one private address evidence record is now created on the case.
Technical:

The following two activities in the change of circumstance workflow have been merged into a single activity:

ParticipantAndCaseProcessing
EvidenceUpdater

The first of these activities, ParticipantAndCaseProcessing, now performs all of the processing in one step. It does this by calling the new API:

curam.healthcare.facade.coc.impl.CoCWorkflowHelper.process
ParticipantsAndCasesAndUpdateEvidence():

The following two APIs that were called by the workflow have been deprecated:

curam.healthcare.facade.coc.impl.CoCWorkflowHelper.
processParticipantsAndCases()
curam.healthcare.facade.coc.impl.CoCWorkflowHelper.
updateEvidence()

PO06636, WorkItem:174773 - Mother enrolled on Medicaid on child's date of birth does not evaluate correctly for Deemed Newborn

Issue Description:

Eligibility for Deemed Newborn requires the child’s mother to be eligible for Medicaid on the child’s date of birth. The information currently used to satisfy this rule results in incorrect eligibility in certain situations because only Newborn evidence is being checked by the rules when determining if the child's mother is eligible on the child's date of birth. When Newborn evidence is not recorded, the child is incorrectly found eligible for the Children category instead of Deemed Newborn, even when the mother is eligible for Medicaid on the child's date of birth.
User Interface Impact: No

Steps to reproduce:

Login to Citizen Portal.
- Submit an Insurance Affordability application on 6/30/2018 for a pregnant woman with a due date of 9/1/2018.
Login as an Insurance Affordability caseworker.
- Authorize the application to create a Streamlined Medicaid product delivery case.
- Change the System Date to 9/1/2018.
- End date the pregnancy evidence 9/1/2018.
Login to the Citizen portal and add a newborn with DOB 9/1/2018.
- Answer No to ‘Was Newborn’s mother enrolled on Medicaid that covers labor and delivery (including Emergency Medicaid) on his/her date of birth?' while processing the change of circumstance.
Process the change of circumstance.
- No Newborn evidence is created due to the answer provided to the "Was Newborn’s mother enrolled on Medicaid that covers labor and delivery (including Emergency Medicaid) on his/her date of birth" question.
The child is incorrectly determined eligible for the Streamlined Medicaid Children category instead of Deemed Newborn due to the absence of the Newborn evidence, even though the mother is eligible for Medicaid on the child's date of birth.

Resolution:

Newborn evidence is just one of a number of pieces of evidence that can be used to satisfy the condition that the mother is eligible for Medicaid on the child’s date of birth.

Deemed Newborn rules have been updated to use additional information to correctly determine a newborn's eligibility. Eligibility is now determined by checking any of the following:

Mother’s Streamlined Medicaid timeline including Emergency and Retroactive Medicaid.
Mother’s Benefit evidence indicating she was receiving Medicaid on the child’s date of birth.
Mother’s Non-Magi Medicaid evidence indicating she was receiving Traditional Medicaid on the child’s date of birth.
Newborn Evidence indicating the mother was enrolled on Medicaid on the child’s date of birth.

While fixing the issue reported, a full review of the Deemed Newborn rules was carried out and some additional changes were made. For details of all changes made to Deemed Newborn rules see WorkItem 237568.

WorkItem:178584 - Update the Person entity in a custom function to avoid locking the datastore

Issue Description:

During the application submission process for an Insurance Affordability application in the citizen portal, in some scenarios when the citizen captured a spousal relationship and proceeded to enroll in a plan, when the Person.maritalStatus datastore attribute was updated during the application submission process at the same time that the plan management enrollment process was initiated, a lock occurred as two processes were started in parallel.

This caused the page to hang, blocking the citizen from proceeding in the enrollment process. There is no indication of an error, or no obvious way to continue. This resulted in the citizen being unable to proceed and enroll on a plan.
User Interface Impact: No

Steps to Reproduce:

Login to the Citizen Portal.
Create an Insurance Affordability application for a two person household containing a spousal relationship.
'Sign and Submit' the application.
From the home page, select 'Enroll in Plans', then 'Shop for Plans'.
Select the members to be included on the health plan and select 'Continue'.
Select the Primary Client and 'Continue' triggering the enrollment process.
A lock on the datastore may occur, causing the page to become unresponsive.

Resolution:

To resolve this issue, the point at when the datastore attribute is updated has been changed to an earlier stage in the intake process. As a result the two processes are not occurring in parallel so the lock no longer occurs and the citizen can proceed.

Technical:

Previously the maritalStatus attribute was updated in curam.healthcare.intake.impl.RelationshipDataIntakeApplicationListener.
The binding for this file was removed from curam.healthcare.impl.Module.java so that it is no longer called.
The maritalStatus attribute is now updated in curam.rules.functions.CustomFunctionUpdateSpouseInformation.

PO07842, WorkItem:193328 - Citizen Portal application banner's welcome message and drop down action menu not working correctly when JAWS screen reader is used

Issue Description:

When a citizen logs into the Citizen Portal application, a welcome message and a drop down action menu that allows the user to reset their password or log out are displayed in the upper right corner of the application banner. When the JAWS screen reader is being used, a user is not able to correctly use the keyboard to access these two items.
User Interface Impact: Yes

Steps to Reproduce:

In the Citizen Portal, create and login as an external user.
View the user's username in the welcome message and select the drop down action menu to view the 'Reset password' and 'Log Out' menu items.
Start the JAWS screen reader.
When the JAWS screen reader is used, the welcome message and drop down action menu cannot be accessed as separate options using the keyboard.

Resolution:

The application banner has been redesigned to now include two separate links, one for the welcome message and one for the drop down action menu. When the JAWS screen reader is being used, a user is now able to use the keyboard to access the two items.

PO07127, WorkItem:195536 - Deemed Newborn's ongoing eligibility incorrectly dependent on mother's continued eligibility for Medicaid

Issue Description:

A child’s eligibility for Deemed Newborn was incorrectly dependent on the child being included in the mother’s household and the mother’s continued eligibility for Medicaid. Loss of Medicaid for the mother resulted in the loss of Deemed Newborn for the child. The mother’s ongoing Medicaid eligibility is not a condition for eligibility for Deemed Newborn.
User Interface Impact: No

Steps to reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application on 6/1/2018 for mother and newborn.
- Mother recently pregnant with pregnancy end date of 6/1/2018.
- Mother was enrolled on Medicaid during pregnancy.
- Newborn’s date of birth 6/1/2018.
- Answer yes to ‘Was Child's mother enrolled on Medicaid that covers labor and delivery (including Emergency Medicaid) on his/her date of birth?’.
Submit and authorize application.
Mother eligible for Streamlined Medicaid and child eligible for Deemed Newborn.
Change the system date to 9/1/2018.
Create new Income record for mother, wages & salaries, $50,000 yearly, start date 9/1/2018 and apply changes.
Mother loses eligibility for Streamlined Medicaid and child also loses eligibility for Deemed Newborn.

Resolution:

A child’s eligibility for Deemed Newborn is no longer dependent on the Mother’s continued eligibility for Medicaid. It is only a requirement for the Mother to be eligible for Medicaid on the child’s date of birth. This is satisfied by checking any of the following:

Mother’s Streamlined Medicaid timeline including Emergency and Retroactive Medicaid.
Mother’s Benefit evidence indicating she was receiving Medicaid on the child’s date of birth in the configured state.
Mother’s Non-Magi Medicaid evidence indicating she was receiving Traditional Medicaid on the child’s date of birth.
Newborn Evidence indicating the mother was enrolled on Medicaid on the child’s date of birth.

Once the child has been determined eligible for Deemed Newborn they are eligible until the end of the month in which child turns one unless the child moves out of state or dies.

While fixing the issue reported, a full review of the Deemed Newborn rules was carried out and some additional changes were made. For details of all changes made to Deemed Newborn rules see WorkItem 237568.

PO07437, WorkItem:210075 - Household Composition is incorrect for tax dependents when the related tax filer is changed

Issue Description:

For a household that contains tax dependents, household composition is incorrectly determined during a change of circumstance when the tax dependency of the tax filers changes from one tax filer to another. In the situation where the mother claims her two children as tax dependents on her tax return and subsequently the tax dependency of the children changes to the father, eligibility is incorrectly determined due to the rules continuing to consider the mother as the tax filer.
User Interface Impact: No.

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application with 4 members: mother, father and 2 children.
- Mother and father are unrelated.
- Mother is the parent of both children.
- Father is the parent of one child.
- Father lives at a different address from the mother and children.
- Mother and father file taxes separately.
- Children are tax dependent on the mother.
- Income for the mother and father is in the Medicaid range.
Submit and authorize the application to create a Streamlined Medicaid product delivery case.
End the tax relationship between the children and their mother.
Create a new tax relationship between both children and the father starting the day after the relationship with the mother ends.
Apply changes.
The Household unit formed for the two children is still based on the mother as tax filer.

Resolution:

The rules have been updated to select the related tax filer for tax dependents based on the period of time. This ensures that when the related tax filer changes, the correct eligibility is determined for the tax filer's dependents.

Technical:

Rule set: EJBServer/components/HCR/CREOLE_Rule_Sets/HealthCare
RuleSet.xml

Rule class: MemberCPRCalculator
- Attribute: taxDependentIndividualRecordsTimeline (new)

Rule set: EJBServer/components/HCR/CREOLE_Rule_Sets/House
holdCompositionRuleset.xml

Rule class: TaxDependentFinancialUnit
- Attribute: relatedTaxFiler (modified to timeline)
- relatedTaxFilerFinancialUnitTimeline (modified)
- doesSpouseAndChildRelationshipExistWithTaxFiler (modified)
- childLivingWithTwoParentsAndParentsDoNotFileTogether (modified)
- childClaimedAsDependentByANonCustodialParent (modified)

Rule set: /EJBServer/components/HCR/CREOLE_Rule_Sets/Streamline
Medicaid/ProductDisplay/StreamlineMedicaidFinancial
Units.xml

Rule class: StreamlineMedicaidFinancialUnits
- Attribute: taxFinancialUnitMemberDetailsList (modified)

Rule set: /EJBServer/components/HCR/CREOLE_Rule_Sets/
StreamlineMedicaid/ProductDisplay/StreamlineMedicaid
TaxHouseholdUnitSubScreen.xml

Rule class: StreamlineMedicaidTaxHouseholdUnitSubScreen
- Attribute: taxHouseholdFinancialUnit (modified)

PO07585, WorkItem:217518 - Unable to create new Tax Filing Status evidence record when previous record was not end dated manually

Issue Description:

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 the system not recognising 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.

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a tax filer with income of $20,000, and an application date of 8/7/2017.
Submit and authorize application.
Edit the Tax Filing Status record of 'Tax Filer' and set effective date to 9/1/2017 and change type to 'Non-Filer'.
- Apply changes.
End date the Tax Filing Status record of ‘Non-Filer’ to 9/20/2017.
- Apply changes.
Create a new Tax Filing Status record of type ‘Non Filer’, with start date 9/21/2017.
- Apply changes.
End date the Tax Filing Status record of ‘Non-Filer’ to 9/24/2017.
- Apply changes.
Create a new Tax Filing Status record of type ‘Tax Filer’, with start date 9/25/2017.
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 evidence 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.

It is now possible for the caseworker to create another Tax Filing Status evidence record of the same type as one that has been succeeded.

This change has been implemented for all dynamic evidence, see WorkItem 237078.

PO07612, WorkItem:220162 - Add a Member guided change does not allow existing member to be set as Primary Caretaker resulting in incorrect coverage

Issue Description:

When adding relationship details for a new household member via the Add a Member guided change wizard, only the member being added can be set as the primary caretaker. If the new household member being added has a primary caretaker who is an existing household member, the caseworker is unable to set the existing member as the primary caretaker. This could occur where the new member being added is a child who has a non-parent caretaker in the household. As a result, incorrect eligibility may be determined as the primary caretaker indicator is used as evidence to establish eligibility for the Parent/Caretaker coverage category for Streamlined Medicaid.

User Interface Impact:
Yes - an additional question is added on the 'Personal Information' page of the Add a Member guided change.

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Search for and open an existing Insurance Affordability application or integrated case.
From the page action menu, select Guided Change > Add a Member.
Add a new member that is a child and whose primary caretaker is an existing household member.
Proceed through the wizard completing as necessary.
On the 'Relationship' page the primary caretaker indicator can only be used to indicate that the child is the primary caretaker of an existing household member. It is not possible to record an existing household member as the primary caretaker of the child.

Resolution:

When adding a new household member via the Add a Member guided change wizard, a caseworker can now record if the new household member has a primary caretaker (other than a parent) who is an existing household member.

A question has been added to the 'Personal Information' page to determine if the new household member has a primary caretaker (other than a parent) in the household. If the checkbox is not selected, there is no change to how the information is displayed on the 'Relationship' page. However if the checkbox is selected, the Participant and Related Participant(s) are switched on the 'Relationship' page, so that, when the primary caretaker checkbox is selected, the existing household member is recorded as the non-parent primary caretaker.

PO07606, WorkItem:220380 - Unhandled server exception occurred when creating Member Relationship evidence if case participant or related participant was not specified

Issue Description:

When a caseworker is adding new Member Relationship evidence to an Insurance Affordability integrated case an un-handled server exception is thrown if the ‘case participant’ and ‘related participant’ fields are left blank.
User Interface Impact: Yes

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Submit and authorize application.
Create a new Member Relationship record with blank ‘Case Participant’ and ‘Related Participant’.
An un-handled server exception occurs.

Resolution:

The following corrections have been made to the latest version of dynamic evidence for Member Relationship:
a) Case Participant marked as mandatory.
b) Case Participant defaulted to blank.

a) Case Participant marked as mandatory
The Case Participant drop-down field has been marked as mandatory.

b) Case Participant defaulted to blank
The Case Participant drop-down has been updated to default to blank. This means that the caseworker must select the correct case participant before saving the record. If a case participant is not selected, a validation 'Case Participant must be entered' is displayed.

When the record is created for a case participant, the case participant field appears as read-only on the modify screen.

These changes to case participant have been implemented across all dynamic evidence that allow a case participant to be selected when creating a record through the user interface. For details of these changes see WorkItem 237075.

PO07632, WorkItem:222048 - Tax filing status incorrectly causing ineligibility for Retroactive Medicaid

Issue Description:

An individual’s tax filing status and whether or not they are claimed as a tax dependent by a person external to the household should not impact their eligibility for Retroactive Medicaid.

When a caseworker indicates that an applicant is a tax dependent on a person external to the household, the applicant is found eligible for Streamlined Medicaid assuming all other eligibility conditions are met, but Retroactive Medicaid is incorrectly denied for the individual.

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Indicate the person is claimed as a Tax Dependent by an external member when entering Tax Filing Status information.
Submit and authorize the application to create a Streamlined Medicaid product delivery case.
Create Medical Bills evidence covering the retroactive period.
Back date all relevant evidence to cover the retroactive period.
Check Retroactive Medicaid eligibility.
Person is ineligible for Retroactive Medicaid eligibility due to being claimed as a dependent by an external member.

Resolution:

Retroactive Medicaid rules have been modified to remove the restriction which prevented eligibility when an individual was claimed as a tax dependent by an external member.

When a caseworker records the tax filing status for an individual and indicates the individual is claimed as a tax dependent by an external member, the individual is eligible for Retroactive Medicaid assuming all other eligibility conditions are met.

Technical:

The following rules changes were made:

Rule set:
- EJBServer/components/HCR/CREOLE_Rule_Sets/
  StreamlineMedicaidEligibilityAndEntitlementRuleset.xml
Rule class: FinancialsCPRCalculator
- Attribute: taxFilingStatusTimeline (modified)
- Attribute: isTaxFiler (new)

PO07658, WorkItem:224652 - Long application case names overlap with application case reference numbers in the context panel

Issue Description:

In an Insurance Affordability application case that includes multiple participants, when the application name is long it overlaps with the application case reference number in the context panel.

**User Interface Impact: **Yes

Steps to Reproduce:

Login as an administrator.
Select the Administration workspace tab.
In the Shortcuts Panel, select Universal Access > Application Cases.
Edit the Insurance Affordability application case, changing its name to 'Insurance Affordability Application Application' and click 'Save'.
Login as an Insurance Affordability caseworker and search for (or create) an application with more than one participant.
Open the application and observe the application name overlaps with other information in the context panel.

Resolution:

If the application name is too long, an ellipsis now appears at the end of the field. This holds true even if the Shortcuts Panel is further dragged to the right.

PO07720, WorkItem:226628 - Comments field on the 'Authorize Program' modal for an application case is too small when selecting to use an existing integrated case during the authorization process

Issue Description:

When authorizing a program for an Insurance Affordability application case, the user is presented with a list of the existing integrated cases for the applicants in the ‘Authorize Program’ modal. In this instance when the integrated cases are displayed within the modal for selection by a user, the Comments field becomes too small and the user is unable to enter text.

User Interface Impact: Yes

Steps to Reproduce:

Login as an administrator and ensure that the Integrated Case Strategy on the program associated with the Insurance Affordability application is 'Existing (Any Client Match) or New'.
Login as an Insurance Affordability caseworker.
Register a new person.
Create an application for the new person.
Complete and authorize the application and ensure that an integrated case gets created.
Create another application for the same person.
On the 'Authorize Program' modal for the second application, the existing integrated case is listed with the 'Comments' field below it.
The 'Comments' field is too small to enter text into.

Resolution:

The 'Comments' field on the modal has been increased in size and it is now possible for a user to enter text into the field.

Technical:

The name and location of the client page containing the 'Comments' field that has been increased in size is as follows:
./Curam/components/CommonIntake/Delivery/Authorisation/
UseExistingAnyClientsMatchOrCreateNew/Authorisation_
useExistingAnyClientsMatchOrCreateNewView.vim

PO07733, WorkItem:226933 - Missing Advanced Evidence Sharing configurations

Issue Description:

The following Advanced Evidence Sharing configurations are missing:

Absence evidence sharing from Insurance Affordability Application (AC) to Income Support (IC)
Absence evidence sharing from Income Support (IC) to Insurance Affordability Application (AC)
Absence evidence sharing from Income Support (IC) to Insurance Affordability (IC)
Demographics evidence sharing from Insurance Affordability (IC) to Exemptions Application (AC)
Addresses evidence sharing from Insurance Affordability (IC) to Person Record.

which means that it is not possible to share these evidence types between these case types.

User Interface Impact: No

Steps to Reproduce:

Login as an administrator.
Select the Administration Workspace tab.
From the Shortcuts Panel, select Rules and Evidence > Evidence Sharing.
On the list page identify that the above sharing configurations are missing.

Resolution:

The missing configurations have been added to ../EJBServer/components/HCR/data/initial/EvidenceBroker
Config.dmx and are now visible in the Administration application.

WorkItem:231372 - Inconsistent titles across Add a Member guided change wizard pages results in accessibility issues

Issue Description:

When the caseworker is adding a member via the Add a Member guided change wizard, JAWS reads out a different title for each wizard page. The wizard title changes on each page and mirrors the current page. This is confusing for the caseworker as it indicates they have left the wizard when, in fact, they are still navigating through the wizard pages.

User Interface Impact: Yes

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Submit and authorize application.
From the page action menu select Guided Change > Add a Member.
Start JAWS 18 if not already started.
Complete the wizard, navigating from page to page.
Different titles are output for each wizard page - Participant Details, Personal Information, etc.

Resolution:

Wizard page titles throughout the Add a Member guided change wizard have been updated. The title is now set to 'Add Member' on all pages. This indicates to the caseworker that they are within a wizard as they navigate through its pages using a screen reader.

PO07811, WorkItem:231542 - Enrolled on Medicaid field on Former Foster Care evidence is misspelled

Issue Description:

The label 'Enrolled on Medicaid' on the Former Foster Care dynamic evidence type is misspelled and reads 'Erolled on Medicaid'.

User Interface Impact: Yes
Steps to Reproduce

Login to the Insurance Affordability external application.
Submit an application for a father and a son.
Login as an Insurance Affordability caseworker.
Locate the submitted application under ‘My Applications’.
Authorise the application.
Navigate to the Related Cases tab and open the Insurance Affordability Integrated Case.
Select the Evidence tab and add new Former Foster Care evidence for the son.
Enrolled on Medicaid spelling mistake is shown.

Resolution:

The misspelling has been corrected on the properties file associated with the Former Foster Care dynamic evidence type.

WorkItem:231953 - Add a Member guided change submitted via the Evidence tab is not displayed on the guided change page unless refreshed

Issue Description:

When the caseworker adds a person to the household using the Add a Member guided change wizard, the information is not displayed under the submitted section on the guided change page. The caseworker must refresh the page to see the recently submitted guided change.

This only happens when the caseworker selects the Add a Member guided change wizard on the guided change page via the evidence tab. When a person is added via the guided change from the action menu, the page refreshes automatically.

The reason it does not refresh when accessed via the evidence tab is because the guided change page is already open when the Add a Member guided change wizard is selected and the page is not refreshed if already on that page.

User Interface Impact: Yes

Steps to Reproduce:

Login as an Insurance Affordability caseworker
Create an Insurance Affordability application for a person.
Submit and authorize application.
Open the Evidence tab and click on Guided Change.
Select the Add a Member inline page action.
Complete the Add a Member Guided Change wizard.
The submitted Add a Member Guided Change is not displayed on the Guided Change page.
The caseworker has to refresh the Guided Change page to see the recently submitted Guided Change.

Resolution:

When the caseworker adds a person to the household using the Add a Member guided change via the evidence tab the guided change page now refreshes automatically and displays the recently submitted guided change.

Technical:

This issue has been addressed by updating the following UIM page:

HCRAddMemberWizard_summary

so that it explicitly calls either

HCR_guidedChangeFromIntegratedCase or
HCR_guidedChangeFromAppCase

based on an Action_ID passed back from the server.

Where to navigate to was previously determined using the following resolve script:

HCRAddMemberWizard_resolveGuidedChangePage

However, resolve scripts do not refresh a page if you are already on that page.

PO07836, WorkItem:232926 - Help Text and Tool Tip content displayed at the end of an Insurance Affordability application overlaps

Issue Description:

When creating an Insurance Affordability application from within the Citizen Portal, a user can view a list of additional benefits for which they may be eligible at the end of the application process. When the user hovers over the help icon for one of the benefits listed, the help text and tool tip content for the benefits are both displayed and overlap each other. This makes it difficult for a user to read and understand the content.

User Interface Impact: Yes

Steps to Reproduce:

Open the Citizen Portal.
Select to apply for assistance, select to create an account to register in the Citizen Portal, and proceed to create an Insurance Affordability application.
Answer the questions in the Insurance Affordability application script.
On the 'Sign and Submit' page at the end of the application that displays information about Healthcare Options, hover over the help icon for one of the other benefits listed for which a client may be eligible.
The tool tip and help text content are both displayed and overlap.

Resolution:

This issue has been addressed and the help content displayed for the list of benefits no longer overlaps.

WorkItem:237568 - Deemed Newborn rules for Streamlined Medicaid determine incorrect eligibility in certain situations

Issue Description:

The rules for the category of Deemed Newborn for Streamlined Medicaid were determining incorrect eligibility in certain situations.

Deemed Newborn eligibility was incorrectly tied to the mother’s continued eligibility for Medicaid. Loss of Medicaid for the mother incorrectly resulted in loss of Deemed Newborn for the child. Changes in income, which should not impact eligibility, also resulted in the loss of Deemed Newborn for the child.

For a child to be eligible for Deemed Newborn, the child’s mother must be eligible for Medicaid on the child’s date of birth. If the caseworker did not enter Newborn evidence, this resulted in the child incorrectly receiving the Children category of Streamlined Medicaid instead of Deemed Newborn. Newborn evidence is just one of a number of pieces of evidence that can be used to satisfy the mother was eligible for Medicaid on the child’s date of birth. Only Newborn evidence was being checked by the rules.

User Interface Impact: No

Steps to Reproduce: Refer to the steps to reproduce provided in the related work items for examples of how to reproduce this issue.

Related WorkItems: 174773, 195536

Resolution:

The rules to determine the category of Deemed Newborn for Streamlined Medicaid have been revised to fix the related WorkItems and some changes required following a review of these rules.

The revised Deemed Newborn rules are:

Child is under 1 years of age AND
Mother is enrolled on Medicaid in the state on child’s date of birth AND
Child is resident in the state AND
Child is eligible from Date of Birth to the end of the month in which the child turns 1

Child is under 1 years of age
Application for Deemed Newborn can be made up to the day before the child’s first birthday.
\ Mother is enrolled on Medicaid in the state on child’s date of birth
Mother is enrolled on Medicaid in the configured state on the child’s date of birth. This rule is satisfied by checking any of the following:

Mother’s Streamlined Medicaid Timeline including Emergency and Retroactive Medicaid
Mother’s Benefit evidence indicating she was receiving Medicaid on the child’s date of birth in the configured state
Mother’s Non-Magi evidence indicating she was receiving Traditional Medicaid on the child’s date of birth
Newborn Evidence indicating the mother was enrolled on Medicaid on the child’s date of birth

The child’s eligibility for Deemed Newborn is not dependent on the mother’s continued eligibility for Medicaid. It is only a requirement for the mother to be eligible for Medicaid on the child’s date of birth.
\ Child is resident in the state
The normal residency rules are applicable to Deemed Newborns with one exception. If the child's date of birth is prior to the application date, the residency rules for the period from date of birth to the day prior to application date are ‘undetermined’ provided the residency rules pass on the application date. If the residency rules fail on the application date, they also fail for the prior period.
\ Child is eligible from Date of Birth to the end of the month in which the child turns one
Once a child has been determined eligible for Deemed Newborn they are eligible until the end of the month in which child turns one unless the child moves out of state or dies.
\ Citizenship, SSN & Income Rules
Citizenship, SSN and Income rules are not applicable to Deemed Newborns. Any changes to income do not impact a child’s ongoing eligibility for the Deemed Newborn category.
\ Display Rules
Display rules have been updated to reflect the ‘undetermined’ decision where child’s date of birth is prior to application date. A reason of ‘Deemed Newborn Eligibility’ is now displayed on the Income Counted Information section to explain why the Deemed Newborn’s financial unit members income is not counted.

Technical:

Eligibility and Entitlement Rule changes

Rule Set: /EJBServer/components/HCR/CREOLE_Rule_Sets/
CHIPEligibilityAndEntitlementRuleset.xml

Rule Class: MemberEligibilityCalculator
- Attribute: coverageStartDate
- Description: modified to prevent eligibility aligning back before date of birth

Rule Set: /EJBServer/components/HCR/CREOLE_Rule_Sets/
StreamLineMedicaidEligibilityAndEntitlementRuleset.xml

Rule Class: StreamlineMedicaidProductCase
- Attribute: extendedPeriodTimeline
- Description: modified to include deemedNewBornExtendedPeriodTimeline to list of conditions for extension
- Attribute: deemedNewBornExtendedPeriodTimeline
- Description: new attribute to calculate timeline for Deemed Newborn before date of application
- Attribute: membersAppliedForCoverageWithDeemedNewBorn
- Description: new attribute to calculate timeline for coverage period including deemed newborn before date of application
Rule Class: MemberEligibilityCalculator
- Attribute: mother
- Description: removed, not used
- Attribute: isMotherEligibleTimeline
- Description: removed, not used
- Attribute: isEligibleTimeline
- Description: modified to correct conditions for Deemed Newborn Eligibility
- Attribute: newBornEligibilityDeterminator
- Description: new, access to the calculator for determining Deemed Newborn Eligibility for the individual
- Attribute: deemedNewbornDOBToApplicationDateTimeline
- Description: new, references same attribute on newbornEligibilityDeterminator
- Attribute: isDeemedNewBorn
- Description: new, true if individual has any Deemed Newborn period
- Attribute: isDeemedNewBornEligibleTimeline
- Description: new, references same attribute on newbornEligibilityDeterminator
- Attribute: isDeemedNewBornEligibleTimelineBeforeDateApplied
- Description: new, references same attribute on newbornEligibilityDeterminator
- Attribute: isMemberEligibleTimeline
- Description: modified to revert alignment call to getAdverseActionsForCHIPAndSM2 and deprecated getAdverseActionsWithNewBornProcessing1
- Attribute: coverageStartDate now getCoverageStartDateForSMIndividual
- Description: modified to prevent prevent eligibility aligning back before date of birth, takes care to record Deemed Newborn start dates to control product creation where Deemed Newborn prior to application start
Rule Class: FinancialsCPRCalculator
- Attribute: isDeemedNewBornEligibleTimeline
- Description: default to false forever rather than null
- Attribute: hasPassedFinancialRulesTimeline
- Description: include Deemed Newborn timeline in condition for passing financials
Rule Class: NewBornEligibilityDeterminator
- Description: Re-written to match business requirements
Rule Class: motherEligibilityCalculatorOnChildDOB - removed ()
Description: Removed, no longer used (removes attribute isMotherEligibleOnMedicaidWithinCurrentReassessmentPeriod referenced in APAR PO06636)

Display Rule changes

Rule Set:

/EJBServer/components/HCR/CREOLE_Rule_Sets/
StreamlineMedicaid/ProductDisplay/StreamlineMedicad
FinancialUnitSubScreen.xml

Rule Class: StreamlineMedicadFinancialUnitSubScreen
- Attribute: incomeCounted
- Description: include logic for Deemed Newborn
- Attribute: reasonForIncomeNotCounted
- Description: include logic for Deemed Newborn

Rule Set: /EJBServer/components/HCR/CREOLE_Rule_Sets/
StreamlineMedicaid/ProductDisplay/StreamlineMedicad
FinancialUnits.xml

Rule Class: StreamlineMedicadFinancialUnits
- Attribute: membersPassingFinancialsUsingMAGIIncomeTimeline
- Description: include logic for Deemed Newborn

Rule Set: /EJBServer/components/HCR/CREOLE_Rule_Sets/
StreamlineMedicaid/ProductDisplay/StreamlineMedicad
NonFinancialCategory.xml

Rule Class: StreamlineMedicadNonFinancialCategory
- Attribute: membersList
- Description: includes Deemed Newborn period
- Attribute: residencyMessageList
- Description: undetermined where Deemed Newborn before date applied
- Attribute: eligiblityMessageList
- Description: included Deemed Newborn as pass

Rule Set: /EJBServer/components/HCR/CREOLE_Rule_Sets/
StreamlineMedicaid/ProductDisplay/StreamlineMedicaid
TaxHouseholdUnitSubScreen.xml

Rule Class: StreamlineMedicaidTaxHouseholdUnitSubScreen
- Attribute: incomeCounted
- Description: include logic for Deemed Newborn

Property changes

File: /EJBServer/components/HCR/CREOLE_Rule_Sets/Resource/
curam/hcrcase/rules/StreamlineMedicaidDisplay.properties
- Property: MemberIncomeNotCounted.Reason.DeemedNewBorn
- Description: New

Java class: /EJBServer/components/HCR/source/curam/hcrcase/creole/
statics/impl/Statics.java
- Method: shiftToStartDayOfMonth
- Description: new, shifts date passed in to month start
- Method: getAdverseActionsWithNewBornProcessing1
- Description: deprecated, use getAdverseActionsForCHIPAndSM2 for alignment. Deemed Newborn no longer tied to alignment logic.
- Method: getDeemedNewbornEligibleTimeline
- Description: deprecated, no longer used
- Method: isDeemedNewbornInPreviousCertificationPeriod
- Description: deprecated, no longer used
- Method: isMemberEligibleOnMedicaidWithinCurrentReassessmentPeriod
- Description: deprecated, no longer used
- Additional Statics helper methods added to the class:
- Method: hasIntervalValue
- Description: determines if a boolean timeline contains at least one interval of type passed.
- Method: containsCodeTableItem
- Description: determines if a code table timeline contains the code passed
- Method: alignMonthStartAndEnd
- Description: adjusts true periods of a boolean timeline to start and end of month
- Method: isTrueOnDate
- Description: true if the boolean timeline is true on the date passed

PO06698, WorkItem:238380 - Validation prevents multiple non-overlapping Citizen Status records for a participant

Issue Description:

Caseworkers are unable to create multiple non-overlapping Citizen Status evidence records for a given participant on an Insurance Affordability integrated case. This prevents the user from capturing a change in Citizen Status for an individual over the lifetime of the case.

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application for a person.
Submit and authorize application.
End date the existing Citizen Status evidence record.
Create a new Citizen Status evidence record that does not overlap with the existing Citizen Status record.
The new Citizen Status record cannot be created due to the validation 'A Citizen Status record already exists for this Participant'.

Resolution:

The meta-data for the Citizen Status dynamic evidence type has been corrected, and multiple non-overlapping Citizen Status evidence records can now be added for a participant on an Insurance Affordability integrated case.

WorkItem:238506 - Update Open Enrollment Period for 2019

Issue Description:

No open enrollment period configuration for 2019 for Insurance Affordability is available.

User Interface Impact: No

Steps to Reproduce:

Login as an administrator.
Navigate to the Open Enrollment Period tab under the Health Care Reform shortcut.
No open enrollment period for 2019 is configured.

Resolution:

A new open enrollment period configuration is now available. The configuration is: Start Date 11/1/2018, End Date 12/15/2018, Coverage Start Date 1/1/2019 and Coverage End Date 12/31/2019.

Child Welfare

PO02781, WorkItem:116474 - Intake Narrative Smart Panel save icon is updated incorrectly when text is saved

Issue Description:

When text is entered into the Intake Narrative Smart Panel of the Intake Assistant and the user selects to save the text, the text is saved but the save icon is then updated to display an X and the tool-tip displays incorrect help text.

User Interface Impact: No

Steps to Reproduce:

Login as a Child Welfare intake worker.
Create a new Intake.
Type text into the Intake Narrative Smart Panel.
Click on the Save icon.
The Intake is saved but the save icon is updated to display an X and the tool tip displays incorrect help text.

Resolution:

When a user saves text within the Intake Narrative Smart Panel, the Save icon is now updated to display a green tick when the save request has completed and the tool tip now correctly displays help text.

PO03135, WorkItem:116476 - Adding an apostrophe to any address field for a Reporter in an Intake causes an application error

Issue Description:

When a caseworker enters an address containing an apostrophe for a Reporter in the Intake wizard, an un-handled server exception is thrown by the application.

User Interface Impact: No

Steps to Reproduce:

Login as caseworker.
Create an Intake using the Intake wizard.
Add a Reporter to the Intake.
Enter 'Fort Qu'appelle' into the city field of the address.
Click 'Next'.
Issue: an un-handled server exception is thrown.

Resolution:

This issue arose due to the construction of incorrect SQL, which is created dynamically, to search for participant roles. The underlying issue has been resolved and the Reporter address can now be entered with apostrophes, thereby allowing the caseworker to successfully complete the Intake wizard.

PO07724, WorkItem:226909 - Incorrect navigation within the New Provider wizard when selecting the Enter key

Issue Description:

When a user hits the 'Enter' key within the New Provider wizard in a page with 'Back' and 'Next' buttons, the user is navigated to the previous page instead of the next page in the wizard.

**User Interface Impact: **No

Steps to Reproduce:

Login as a Child Welfare intake worker and create a new 'Child Protection Services' Intake.
Create an Intake participant.
Select the 'Open Intake' action from the Intake Assistant to create an Intake case.
Navigate to the Providers page under the Participants tab and select to create a new provider.
In the 'Provider Information' step of the wizard, enter the name of a registered provider and select 'Next' to view a matched provider.
Select the matched provider and hit the 'Enter' key.
The user is navigated back to the previous page of the wizard.

Resolution:

Navigation has been corrected within the affected pages of the wizard and when the user hits the 'Enter' key they are now navigated to the next page in the wizard.

PO07742, WorkItem:227769 - Unhandled server exception occurs when attempting to place a child that is a participant of multiple intakes associated to the same investigation

Issue Description:

When multiple intakes are created for the same participants and the intakes are associated to the same Investigation case, an unhandled server exception error occurs when a caseworker attempts to create a removal record and place the child.

**User Interface Impact: **No

Steps to Reproduce:

Prerequisites:

Create an Intake case with Category: ‘Child Protection Services’, Type: ‘Child Abuse or Neglect’ and with today's date. The Intake should have two participants, the first one a minor with the role of 'Alleged Victim' and the second an adult with the role of 'Alleged Maltreater'.

The Intake should be screened in and an Investigation case created. From the Investigation case, create a new contact within the contact log before logging out of the application. Push the server date forward to the following day.

Create a new Intake with the same details for the Intake participants as used in the prerequisites (i.e. with the same participant names) and select ‘Exact’ match on the ‘New Participant’ modal.
From the ‘Administration’ tab of the Intake case, select the ‘Related Cases’ tab and click ‘New’.
Click the search option (magnifying glass icon) beside the ‘Related Case Reference’ field and enter the Investigation case ID for the Investigation case created previously, search for and select it, and select to 'Save' the new case relationship.
Select the ‘Recommendation’ tab, click ‘Capture’, select recommendation of ‘Screen In’, and submit the Intake.
Approve the Intake and create an Investigation case.
From the ‘Participants’ tab of the Investigation case, register both participants via the ‘Register’ option on the action menu (a date of birth and an address will be required).
Create an Ongoing case from the Investigation case context panel action menu.
Navigate to the ‘Removals and Placements’ tab, select 'New Removal', enter the required details and click ‘Save and Place’.
An unhandled server exception occurs.

Resolution:

An unhandled server exception no longer occurs when a caseworker attempts to place a child who is a participant on multiple intakes associated to the same Investigation case. When the caseworker selects to place the child when creating the removal record, the ‘New Placement’ modal displays allowing the caseworker to place the child as expected.

Technical details:

A multiple record exception was occurring in the application if / when the ‘readByCaseParticipantRoleID’ operation was invoked on the ‘ContactComplianceInfo’ entity where two or more records existed for the specified case participant role. Now the ‘readByCaseParticipantRoleID’ operation on the ‘ContactComplianceInfo’ entity has been deprecated and has been replaced by a readmulti search, ‘searchByCaseParticipantRoleID’. All default calls to ‘readByCaseParticipantRoleID’ have been replaced by ‘searchByCaseParticipantRoleID’.

PO07781, WorkItem:229808 - Unhandled server exception occurs when too large a number of characters are entered into the Comments field when capturing a recommendation on an Intake case

Issue Description:

When submitting an intake for approval an Intake worker can enter comments to explain the rationale for the recommendation to either screen in or screen out an Intake. An un-handled server exception occurs when text longer than 300 characters is entered into the Comments field when capturing a recommendation on an Intake case.

User Interface Impact: Yes

Steps to Reproduce:

Login as a Child Welfare intake worker.
Create a 'Child Protection Services' intake.
Add two participants with roles as 'Alleged Victim' (for the child) and 'Alleged Maltreator'.
Add an allegation.
Capture recommendation information with a Recommendation of 'Screened In' and enter text larger than 300 characters into the 'Comments' field.
Click on 'Submit'.
An unhandled-server exception occurs.

Resolution:

When capturing a recommendation as part of an intake submission, if a comment with text longer than 300 characters is entered into the ‘Comments’ field, the intake is now submitted for approval as expected. The comment is displayed under the ‘Comments’ field on the ‘Recommendation’ screen as well as on the ’Notes’ page within the ‘Contacts’ tab. The comment is no longer displayed under the ‘Status History’ section of the ‘Administration’ tab.

Additionally when a supervisor subsequently approves, overrides, or returns a recommendation, the text entered into the ‘Comments’ field is displayed as a note on the ’Notes’ page within the ‘Contacts’ tab on the Intake case. It is no longer displayed under the ‘Status History’ section of the ‘Administration’ tab.****

Technical:

The intake recommendation comment text is now only stored on the ‘NOTE’ database table which has a character limit greater than 300 characters. The comment text is no longer stored on the ‘CASESTATUS’ table also.

PO07854, WorkItem:234204 - Browser spell check not working in Intake Narrative Smart Panel

Issue Description:

When browser spell checking was enabled, spell check was not working in the Intake Narrative Smart Panel and misspelled words were not being highlighted.

User Interface Impact: No

Steps to Reproduce:

Login as a Child Welfare intake worker.
Create a new Intake.
On the Intake Assistant, navigate to the Smart Panel and enter misspelled words.
The misspelled words are not highlighted.

Resolution:

Browser spell checking for the Intake Narrative Smart Panel has now been enabled and highlights misspelled words.

Technical:

Turning on the browser spell checker for the Smart Panel is achieved by adding the following entry:

config.disableNativeSpellChecker=false;

to the following java-script file:

../Curam/components/ChildServices/WebContent/
cefwidgets/ckeditor_settings/curam_ccs_config.js

PO07878, WorkItem:235074 - Information displayed on the 'Edit Discharge Date' modal does not default to the information previously entered when the child was initially discharged

Issue Description:

When a child is returned to the child’s own home, the caseworker enters a date of discharge from the child’s removal. This date of discharge can be modified if entered in error. On modifying the ‘date of discharge’, the information displayed on the ‘Edit Discharge Date’ modal does not default to the most recently saved information.

User Interface Impact: Yes

Steps to Reproduce:

Login as a Child Welfare caseworker.
Create a new Ongoing Case for a minor.
Create a home removal for the child, selecting a removal date and time two days in the past along with a reason and narrative text.
Create a placement for the child.
Discharge the child from the home removal, entering the following information:
From the newly created Removal record action menu, select the 'Discharge' option.
Set the 'Date' to be 1 day ago and select any time that is not 00:00.
Set the 'Reason' as 'Return Home'.
Enter text in the 'Narrative' text box.
Select to edit the discharge date of the home removal.
The Date defaults to the current date and the time to 00:00. The Reason originally entered is not displayed, and the Narrative field is empty.

Resolution:

The information entered when discharging a child from a home removal is now displayed on the 'Edit Discharge Date' modal.
Additionally, the 'Discharge Child' and 'Edit Discharge Date' modals have been been widened.

WorkItem:236683 - Unhandled server exception occurs when too large a number of characters are entered into the Summary field when capturing a recommendation in an Investigation case

Issue Description:

An un-handled server exception occurs when text longer than 300 characters is entered into the Summary field when capturing a recommendation on an Investigation case.

User Interface Impact: No

Steps to Reproduce:

Login as a Child Welfare intake worker.
Create a 'Child Protection Services' intake.
Add two participants with roles as 'Alleged Victim' (for the child) and 'Alleged Maltreator'.
Add an allegation.
Capture recommendation information with a Recommendation of 'Screened In' and submit the recommendation for approval.
Login as a Child Welfare intake supervisor and select the approval task for the submitted intake.
Approve the intake.
Login as a Child Welfare investigator and create an investigation case that includes both of the intake participants using the task created after approval of the intake.
Register the two participants as persons.
Create a Contact in the Contact Log with a purpose of 'Initial Contact with Alleged Victim'.
Dispose the allegation, selecting a disposition of 'Substantiated'.
Select the 'Make Recommendation' action from the tab level action menu of the Investigation case.
Enter text larger than 300 characters into the 'Summary' field.
An unhandled-server exception occurs.

Resolution:

A validation has now been added to prevent the user from entering more than 300 characters into the Summary field.

Child Welfare SDM

PO03005, WorkItem:116478 - Screen Out Reason information is not saved correctly when entered during the Intake recommendation process

Issue Description:

When an Structured Decision Making Intake worker completes a Screening assessment within an Intake that results in a recommendation of 'Screen Out', the Intake worker must then enter a Screen Out Reason before submitting the intake for approval. When the Intake worker enters a Screen Out Reason and attempts to submit the Intake for approval, the Intake worker incorrectly receives a validation message indicating that no Screen Out Reason has yet been entered.

User Interface Impact: No

Steps to Reproduce:

Login as a Structured Decision Making Child Welfare intake worker.
Create a 'Child Protection Services' intake.
Create participants - Alleged Victim and Alleged Maltreater.
Select Actions > Open Intake to open the Intake case.
Complete the Screening assessment so that no allegations are created and 'Screen Out' is recommended (answer 'No' or 'None' to all questions).
Navigate to the Recommendations tab.
Select the 'Add Information' action item.
Select a Priority and Screen Out Reason, enter text into the Comments field and select to 'Save'.
Select the 'Submit' action item within the Recommendation tab.
Answer 'Yes' to the confirmation message 'Do you want to submit intake details for approvals?' that is displayed in the Submit Recommendation modal.
The following error message is displayed, 'Please enter a Screen Out Reason.'

Resolution:

The 'Screen Out Reason' entered on the Add Information modal is now correctly saved and the Intake worker is able to successfully submit the Intake for approval.

Common Evidence

PO04814, WorkItem:101643 - Unable to add a person that was previously an absent parent on an Income Support integrated case to the case as a new household member

Issue Description:

Common Evidence validations prevent an absent parent that has returned from the household from being recorded on an Income Support case as a Household Member.

To correctly represent a parent's return to the household, a new Household Member evidence record is required for the returning parent and the existing Absent Parent evidence record should be end dated.

However a validation occurs because the Absent Parent evidence record is still active, so a new Household Member evidence record cannot be created. It is not possible to end date the Absent Parent evidence, so the scenario cannot be accurately recorded.

User Interface Impact: No

Steps to Reproduce:

Login an an Income Support caseworker.
Create a Food Assistance case containing two parents and a child.
For the scenario where the father moves out of the household, end date the Household Member evidence and create new Absent Parent evidence.
Apply the changes and approve the case.
Move the father back into the household after a few months by creating new Household Member evidence for the father.
A validation occurs preventing the father from being added as a Household Member.

Resolution:

To resolve the above scenario, start and end dates have been added to the Absent Parent evidence entity. The Household Member validation has been updated to consider these dates when validating against Absent Parent evidence. This allows the return of absent parents to be accurately recorded on a case.

Technical:

The following changes have been made to resolve this issue:

Nullable start and end dates have been added to the Absent Parent entity.
The AbsentParent.xml evidence generator server meta-data file has been updated to contain reference to the new business dates on the entity.
The AbsentParent.euim client meta-data file has been updated to reference the new start and end dates, with the start date being marked as mandatory. This ensures the dates appear on the maintenance pages.
The following validations have been added:
1. The Absent Parent start date must be specified.
2. The Absent Parent start date cannot be earlier than the Absent Parent's date of birth. {Note: not checked if the Absent Parent is a Representative}
3. The Absent Parent end date cannot be earlier than the start date.
4. The Absent Parent record cannot overlap with an existing Household Member record for the same participant.
The AbsentParentHook points (getDetailsForListDisplay and calcAttributionDatesForCase) have been updated to reference the new business dates.
The AbsentParentExtensionHandler, which is called by the intake script, has been updated to default the Absent Parent start date to the application date.

Note: Taking on this change requires changing the database schema to add the business start and end dates. These new attributes will be added by the current upgrade tooling. The steps for populating the business start date for existing Absent Parent records are outlined in the Merative SPM Upgrade Guide in the chapter entitled 'Addition of business start and end dates to the Absent Parent entity'.

PO07144, WorkItem:196085 - Add a Member Guided Change Wizard cannot be used to re-add a member returning to the household

Issue Description:

When a person returns to a household, the caseworker must re-add them to any appropriate cases. To do this, the caseworker must complete a set of manual steps within the case with no guidance provided as to the correct process to follow. New evidence may need to be created or existing evidence updated.

The caseworker is unable to re-add a member to a case successfully using the Add a Member guided change wizard as it is designed for adding new members only so a manual process must be followed to re-add a member.

This impacts the caseworker as they may expect the Add a Member guided change wizard to cater for re-adding a member also. When they try to use it to re-add a member, they are blocked from doing so towards the end of the process after entering information on pages in the wizard.

User Interface Impact: Yes

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create an Insurance Affordability application with at least two people.
Submit and authorize application.
Remove one member from the household by end dating the member's Application Details and all other related evidence.
Close any tasks that are associated with the removal.
Add any necessary verifications and apply changes.

Sometime later the person who left the household returns and must be re-added to the case

From the action menu select Guided Change => Add a Member.
Search for the case participant to (re-)add (this is the person who was previously removed).
Proceed through the steps of the wizard, completing as necessary.
Validations prevent the caseworker being able to complete the process.

Resolution:

To improve the caseworker experience, caseworkers can now use a Re-add a Member function that reduces the number of steps required to re-add a member to a household. The function will be available from the page action menu, under Guided Change and also from the Guided Change page under the Evidence tab. The Re-add a Member function will now guide the caseworker through the process by:

Automatically creating the evidence required to re-establish the member as an active household member. For Insurance Affordability, this is the Application Details evidence and for Income Support this is the Household Member evidence.
Advising the caseworker as to what additional evidence should be reviewed.

As the Add a Member guided change wizard is not suitable in the scenario where a member returns to the household and is to be re-added to an ongoing case, a validation has been added which prevents an end dated member being selected on the initial case participant page of the Add a Member guided change wizard. This notifies the caseworker early in the process that they should not proceed through the wizard.

Technical:

The content of the validation message may be customized:

/EJBServer/components/ISProduct/message/BpoAddMemberWizard.xml
- ERR_PARTICIPANT_ALREADY_MEMBER_OF_HOUSEHOLD
/EJBServer/components/HCR/message/HCRAddMemberWizard.xml
- ERR_PARTICIPANT_ALREADY_MEMBER_OF_HOUSEHOLD

PO07467, WorkItem:211583 - Add a Member Guided Change Wizard incorrectly forces the entry of relationship information with end dated household members

Issue Description:

In an Insurance Affordability or an Income Support case when a household member is removed and a new member is added using the Add a Member guided wizard, on the Relationship page of the wizard the caseworker is asked to enter a relationship between the new member and the end dated member (who has left the household).

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker.
Create and submit an application for two people.
Authorize the application to create an Insurance Affordability integrated case.
Within the integrated case, remove one of the members from the household by end dating the member's Application Details and all other related evidence.
Close any open task associated with this removal.
Add verifications as necessary and apply changes.
From the tab action menu select Guided Change > Add a Member to add a new member.
Navigate through the wizard to the Relationship page.
On the Relationship page the caseworker is asked to enter a relationship between the new member and the person who is no longer a member of the household.

Resolution:

The Application Details evidence end date for the Insurance Affordability case and the Household Member evidence end date for the Income Support case are now taken into consideration in determining what relationships need to be entered. If the date that the new member is added to the case is after the Application Details or Household Member end date, the relationship is not displayed.

As part of this solution, when applying evidence changes, a validation is encountered if a relationship record does not exist between all members. This validation now excludes end dated members, so that a new participant can successfully be added to the household without having a relationship with a previously removed member.

PO07937, WorkItem:236639 - Person Context Panel is not updated automatically after editing person address evidence

Issue Description:

When a caseworker updates a person's address evidence and changes which address should be considered the person's 'Preferred' address, after the evidence change is saved the Content Panel is not automatically updated to display the new 'Preferred' address.

User Interface Impact: No

Steps to Reproduce:

Login as an Insurance Affordability caseworker or Income Support caseworker.
Register a person.
A private address is created during the registration process and is set as the 'Preferred' address for the person.
Open the Person record.
Navigate to the Evidence tab and add a new address, selecting the 'Preferred' indicator to make the new address the preferred address to be displayed in the Context Panel for the person.
The Context Panel does not refresh automatically to show the new preferred address and shows the previous address instead.

Resolution:

The address displayed in the Context Panel automatically updates to reflect any change that is made to the address evidence for the person.

Technical:

The issue has been resolved by adding the latest version of the Dynamic Evidence Address create and modify pages to the following tab files:

../EJBServer/components/HCR/tab/Participant/HCRPersonHome.tab
../EJBServer/components/HCR/tab/Participant/HCRProspectPerson
Home.tab
../EJBServer/components/ISProduct/tab/Participant/ISPersonHome.tab
..EJBServer/components/ISProduct/tab/Participant/ISProspectPerson
Home.tab

WorkItem:238413 - Inconsistent Label and Cluster Titles on Participant Data Case, Insurance Affordability and Income Support Dynamic Evidence Types

Issue Description:

Case Participant label and cluster titles are inconsistent on Participant Data Case, Insurance Affordability and Income Support dynamic evidence types. Label/cluster titles are missing on some and referred to as Participant on others.
User Interface Impact: Yes

**Steps to Reproduce: **N/A

Resolution:

To promote consistency, label and cluster titles have been updated and are now displayed as 'Case Participant' where appropriate. Only the latest version of the evidence type has been updated.
Technical:

Participant Data Case Evidence Types

Addresses
Label & Cluster property update:
Participant > Case Participant

Bank Account
Label & Cluster property updates:
Participant > Case Participant

Contact Preferences
Label & Cluster property updates:
Participant > Case Participant

Email Addresses
Label & Cluster property updates:
Participant > Case Participant

Gender
Label & Cluster property updates:
Participant > Case Participant

Identifications
Label & Cluster property updates:
Participant > Case Participant

Names
Label & Cluster property updates:
Participant > Case Participant

Phone Numbers
Label & Cluster property update:
Participant > Case Participant

Relationships
Label & Cluster property updates:
Participant > Case Participant
Related Participant (added)

Birth & Death Details
Label & Cluster property updates:
Participant > Case Participant

Insurance Affordability Evidence Types

Application Details
Label property updates:
Participant > Case Participant

Application Filer
Label property updates:
Case Participant (added)

Application Filer Consent
Label & Cluster property updates:
Participant > Case Participant

Authorisation Details
Label & Cluster property updates:
Participant > Case Participant

Authorized Rep
Label property updates:
Case Participant (added)

Benefit
Label property updates:
Case Participant (added)

Citizen Status
Label & Cluster property updates:
Participant > Case Participant

Covered Member
Label & Cluster property updates:
Person > Case Participant (Cluster)
Participant > Case Participant (Label)

Deductions
Label & Cluster property updates:
Participant Details > Case Participant (Cluster)
Participant > Case Participant (Label)

Demographics
Label & Cluster property updates:
Person > Case Participant
Participant > Related Participant

Deprivation
Label & Cluster property updates:
Participant > Case Participant

DHSID Details
Label property updates:
Participant > Case Participant

Disability
Label property updates:
Participant > Case Participant

Enrolled Member
Label & Cluster property updates:
Person > Case Participant (Cluster)
Participant > Case Participant (LabelName)

Excluded Income
Label & Cluster property updates:
Participant > Case Participant

Exemption Reason
Label property updates:
Participant > Case Participant

Former Foster Care
Label property updates:
Participant > Case Participant

Health care Ministry Membership
Label property updates:
Participant > Case Participant

Incarceration
Label property updates:
Case Participant (added)

Income
Label property updates:
Case Participant (added)

Insurance
Label & Cluster property updates:
Person > Case Participant
Participant > Case Participant

Insurance Policy Details
Label property updates:
Participant > Case Participant

Medical Bills
Label property updates:
Participant > Case Participant

Member Relationship
Label property updates:
Case Participant (added)
Related > Related Participant

Military Status
Label property updates:
Participant > Case Participant

Newborn Details
Label property updates:
Participant > Case Participant

Non MAGI Medicaid Eligibility
Label property updates:
individual > Case Participant

Pregnancy
Label property updates:
Participant > Case Participant

Projected Annual Income
Label & Cluster property updates:
Participant > Case Participant

Religious Sect Membership
Label property updates:
Participant > Case Participant

SSN Details
Label property updates:
Case Participant (added)

State Residency
Label property updates

Case Participant (added)

Student
Label property updates:
Participant > Case Participant

Substance Abuse
Label property updates:
Participant > Case Participant

Tax Filing Status
Label property updates:
Participant > Case Participant

Tax Relationship
Label & Cluster property updates:
Related > Related Participant (Cluster)

Income Support Evidence Types

IS Medicaid Eligibility
Label & Cluster property updates:
Name > Case Participant (Label)
Participant > Case Participant (Cluster)
productType > Product Type

Code Removal

WorkItem:224551 - Remove the code for the Dynamic Evidence Corrections feature

In Merative Social Program Management version 7.0.2.0, a feature was delivered where a new action was added to the Dynamic Evidence editor to provide the ability to correct dynamic evidence configurations. The purpose of the feature was to provide a mechanism to correct evidence attribute descriptions, to support correction of misspellings in the original dynamic evidence type and also to support the ability to change a label text where caseworkers may prefer an alternative label name that is more intuitive to them.

A tech note was previously published to highlight the fact that this feature should not be used and was going to be removed from the product in a future release (see /support/spm/flashes/announcing-removal-of-dynamic-evidence-corrections-feature). This announcement was made as further internal testing of the original feature identified that in certain circumstances correcting dynamic evidence impacted the evidence in existence based on this dynamic evidence configuration. Following correction of the dynamic evidence configuration, the evidence resulted in failures to eligibility and entitlement calculations.

The logic for this feature has now been removed from the SPM product. For further details of the artefacts removed and modified as part of this code removal process, please refer to the 'Dynamic_Evidence_Corrections - Code Removal.pdf' document attached to this version of the SPM release notes.

WorkItem:235801 - The hamcrest-core-1.3.jar is no longer delivered as part of the REST Toolkit deliverable

The hamcrest-core-1.3.jar has been removed from the product. This was not used in any product code and will only make an impact if it has been used in the custom code.

WorkItem:237758 - Remove the code for the Provider Match with Watson feature

The Provider Match with Watson functionality has been removed from the Merative Social Program Management product. The Tradeoff Analytics service upon which this solution was built was discontinued and this led to a decision to remove the code artefacts for this feature in SPM 7.0.5.0.

For further details of the artifacts removed and modified as part of this code removal process, please refer to the 'Provider Match with Watson - Code Removal.pdf' document attached to these release notes.

Known Issues

Cúram Enterprise Framework

Integrated Case Management

WorkItem:231476 - After setting Display Case Clients On Case List Pages to true Recently Viewed Cases & Cases Recently Assigned to Me Views still shows Primary Client in the Clients column

Enabling the application property ‘Display Case Clients On Case List Pages’ results in the incorrect display of clients in the Clients column on the following pages:

My cases
Case search
My Case Queries
New Case Query
Cases Recently Assigned to Me
My Recently Approved Cases
Recently Viewed Cases

Cúram Modules

Provider Management

WorkItem:103350 (was previously CPM-2415) - Incorrect underpayment amount created when multiple service invoice line items reassessed due to change in service rate

When there are multiple service invoice line items created and paid for a provider using a fixed amount service rate and payment option of 'pay fixed amount', if the service rate that was used to determine the payment amount is retrospectively modified, e.g. to a higher rate, underpayments are not being generated for all of the affected service invoice line items.

Outcome Management

WorkItem:114547 (was previously CC-1100) - Administration property 'curam.outcomeplanning.referralForAgreementDays' is not working as expected

Outcome Management provides the ability to create agreements where the client(s) can agree in writing to adhere to the activities (services, referrals and actions) that form part of the agreement. A system property exists to filter out referral type activities during the agreement creation process based on a number of days from when the referral was created. This property is currently not being considered when creating an agreement. To work around this issue, the user can view the start date of the referral on the create agreement wizard to determine whether the referral should form part of the agreement.

Solutions

Income Support

WorkItem:239164 - Smart navigator: Searching for Income Support application by reference number and clicking on it throwing error - No tabs configured to open a page for the criteria

Previously, when an application reference number was used to search for an Income Support application the related Income Support application tab was displayed.

Now, when Smart Navigator is enabled and an application reference number is used to search for an Income Support application, the application number is displayed within the search results returned but the following is displayed 'No Tabs configured to open a page for this criteria’ if the item is selected.

Notices

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

Code Removal PDFs

Provider Match with Watson - Code Removal.pdf

Dynamic_Evidence_Corrections - Code Removal.pdf

CSV Release Notes

Release Notes 7.0.5.csv

This CSV file summarizes the individual release notes documented above in the "Improvements, Resolved Issues, Third Party Updates and Code Removals" 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.

Release Notes

Abstract

Content

Introduction

System Requirements

Download

Installation

Improvements, Resolved Issues, Third Party Updates and Code Removals

Known Issues

Notices

Code Removal PDFs

CSV Release Notes

Document Information

More support for:

Software version:

Operating system(s):

Modified date:

Merative ™ Social Program Management 7.0.5.0

Release Notes

Abstract

Content

Introduction

System Requirements

Download

Installation

Improvements, Resolved Issues, Third Party Updates and Code Removals

Known Issues

Notices

Code Removal PDFs

CSV Release Notes

Document Information

More support for:

Software version:

Operating system(s):

Modified date: