Skip to Main Content
Merative Ideas Portal

Shape the future of Merative!

We invite you to shape the future of Merative, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Post your ideas

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the Merative team to refine your idea

Help Merative prioritize your ideas and requests

The Merative team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at Merative works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at Merative, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.


Merative External Privacy Statement: https://www.merative.com/privacy

Status Needs more information
Categories Income Support
Created by Kelli Robinson
Created on Mar 22, 2024

MODIFYING DEFERRED PROCESS TO DISCARD IN-EDIT EVIDENCE ACCOUNT TRANSFER APPLICATIONS

ISD is using CGISS for medical assistance programs so that all future income support programs (SNAP, TANF, CC) can exist on the same integrated case.



We have a scenario that we would like help with. The FFM has the tendency to send states duplicate account transfer applications (same household, same application global id etc)



The business has the expectation that the duplicate application would:


Create an application PDF, and withdraw itself. The challenge that we are running into with the application deferred processing in CGISS is that the data store maps the evidence to the integrated case prior to creating the application pdf.



Do you have any suggestions how we could customize or extend the deferred processing so that when a duplicate FM application is received, we have the ability to accomplish the creation of the application PDF, the withdrawl of the application, and the deletion of the in-edit evidence created as a result of the dupe app?



Business has a concern with these items:


1. Workers having to discard in-edit evidence (time consuming)


2. down stream processes could be initatied by the creation of new in-edit evidence (request for information notices, and if unresolved in-edit evidence potentially causing existing case to close for pending verifications etc.)


Customer Name South Dakota
Persona Based Summary

AS AN ELIGIBILITY SPECIALIST I DO NOT WANT TO HAVE TO DISCARD IN-EDIT EVIDENCE THAT IS CREATED BY FFM APPLICATIONS EACH TIME THE FFM SENDS AN UPDATE FOR A PERSON.

Market Segment General
Type of Request Customer Requirement
Market Opportunity

n/A

Usage frequency + #/type of users impacted

This particular issue has been raised in the Information State Sharing call that is hosted by North Carolina, and which all Curam states are invited to participate in. When this topic was raised, all states expressed that this is a problem for them. So this potentially could impact thousands of users across multiple medicaid states.

CURAM:Workarounds + Proposed Solution

this is the guidance given by Merative support:

Hope you're well.

-When a CGISS application is submitted, rather than stages of a workflow it is just one Java method that calls out to the various stages of the intake process in a defined order.

-At a high level that order is roughly:

  • Go through each program application and create an appropriate integrated case for each.

  • For each case created, create an associated application.

  • For each application move any program applications to a more appropriate application based on configuration.

  • Map the content received from the script to each of the cases. i.e. evidence mapping.

  • Create the application PDF.

  • Set application status to 'Submitted' and perform other post-submit processing.

-There are various hook points available to call throughout this method. These are contained in the AbstractApplicationEvents class:

  • startDeferredSubmission

  • startMappingApplication

  • finishMappingApplication

  • postSubmitting

  • finishDeferredSubmission

-Its possible that one of these hook points could be leveraged to do what the customer might need. The problem with the hook points though is that they are all void returns so there would not be a way to do some custom processing and pass back a parameter to decide that the rest of the processing should not continue. Another possible approach would be to use the finishDeferredSubmission hook to perform the clean up that they need such as deleting the in edit evidence. This could also prove difficult as you would need to ensure you are only deleting the evidence that came from the duplicate application.

-Based on further discussion within the team we recommend that they raise an enhancement request where they should clearly document the problem they face so that the team can consider an enhancement to the product in this area.

  • Attach files
  • Admin
    Graham McCrindle
    Reply
    |
    Apr 16, 2024

    Hi Kelli, Please see request above for additional information if this info is not received by the 2nd May this enhancement request will be closed.

    Thank you,

    Graham McCrindle, CURAM Product Management Team

  • Admin
    Graham McCrindle
    Reply
    |
    Apr 2, 2024

    HI Kelli,

    We have reviewed your enhancement suggestion and require more information to properly understand the issue and the business scenario you are trying to support.

    Based on the information provided, our understanding of your request is:

    • for the system to discard in-edit evidence for "duplicate" account transfer applications


    We have the following questions:

    1. Could confirm what you mean by "global ID"

    2. Also can you confirm if you have any concerns that the "duplicate" account transfer contains different information and why withdrawal would be the correct action?

    3. Can you also advise have CMS provided a business meaningful explanation as to why these duplicates are arriving

    4. Volume of Duplicate account transfers being received by a South Dakota in the last 3 months ?


    Please provide the requested information within 30 days so we may proceed with our evaluation. If we do not hear from you within that timeframe, we will have to close the request due to insufficient information.

    Thank you,

    Graham McCrindle, CURAM Product Management Team

    1 reply
  • Admin
    Graham McCrindle
    Reply
    |
    Apr 2, 2024

    Hi Kelli,

    Thank you for taking the time to share your ideas with us. We are committed to involving our users in building our product roadmap and appreciate your suggestions.

    We will review the information you have provided and get back to you within 30 days. If additional details are required to complete our evaluation, we will send you a request for more information.

    Thank you,

    Graham McCrindle, CURAM Product Management Team