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

Add a new idea Subscribe
Status Not under consideration
Categories Social Program Management Platform
Created by Guest
Created on Mar 12, 2020

RELATED IDEAS

OOTB Class OnlineApplicationProcessor is not extensible

The State of Missouri has a requirement to trigger different workflow base on application type,
but curam.workspaceservices.applicationprocessing.impl.OnlineApplicationProcessor is not customizable as
OnlineApplicationProcessor is not annotated as @Implementable which restrict the project team to customize it compliantly.
We raise a request to provide the ability to use a strategy for selecting which workflow to trigger based on application type.

Customer Name Missouri
  • Attach files
  • Guest
    Reply
    |     Aug 10, 2020

    Hi John,

    We have reviewed your enhancement suggestion. Based on the information provided, our understanding of your request is as follows:
    * You have requested OnlineApplicationProcessor be made extensible to allow you to trigger a different workflow for the new Presumptive Eligibility application implemented.

    We do not fully understand why a different workflow is required for the Presumptive Eligibility application but we feel out offering currently provides sufficient customization points that this approach should not be necessary. The ProcessIntakeApplication workflow is called for all OOTB application submissions. A new application does not require a completely separate workflow, there are many customizations points that exist throughout this process that could be compliantly used. For example, the ProcessIntakeApplication workflow itself could be modified with alternate branches/flows.

    We are closing this request and do not plan to take any further action. If you believe we have misunderstood your request please respond within 7 days with clarifications.

    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.

    Shane McFadden, SPM Offering Management team
    You can find more information on the request process here.

  • Guest
    Reply
    |     Jul 24, 2020

    Hi Shane,

    These artifacts were added to the Missouri codebase by a previous vendor in an attempt to implement Presumptive Eligibility. This is a program in which qualified entities (e.g., healthcare workers) could screen people and enroll them in Medicaid. This program is deployed as a separate webapp to limit exposure of the system by non-State staff, similar to how Universal Access is deployed.

    As for business needs, I can only speculate on the implementors' reasoning, but I would guess that a new intake script was needed that was customized for the qualified entities to use. Therefore, a new schema and IEG script were defined. In addition, once the IEG was submitted they wanted a new application case type defined to distinguish applications for presumptive eligibility from those for standard MAGI eligibility.

    Please let us know if you need anything else.

    Thank you,

    John Coombes

  • Guest
    Reply
    |     Jul 8, 2020

    Hello. I have provided your feedback to the developer. I will post their feedback here upon receipt.

    Regards,

    Maribeth

  • Guest
    Reply
    |     Jul 8, 2020

    Following is a comment from our developer.

    Regards,

    Maribeth Kane

    Hi Shane,

    These artifacts were added to the Missouri codebase by a previous vendor in an attempt to implement Presumptive Eligibility. This is a program in which qualified entities (e.g., healthcare workers) could screen people and enroll them in Medicaid. This program is deployed as a separate webapp to limit exposure of the system by non-State staff, similar to how Universal Access is deployed.

    As for business needs, I can only speculate on the implementors' reasoning, but I would guess that a new intake script was needed that was customized for the qualified entities to use. Therefore, a new schema and IEG script were defined. In addition, once the IEG was submitted they wanted a new application case type defined to distinguish applications for presumptive eligibility from those for standard MAGI eligibility.

    Best regards,
    Jason

  • Guest
    Reply
    |     Jun 19, 2020

    Hi Maribeth,

    Thanks for your previous response and the attachment sent by mail.

    The attachment was a zip file that contained the actual customized artefacts (the intake workflow, IEG scripts and associated datastore).

    This is useful information but needs to be supplemented by the questions we asked previously, most crucially the business need for doing this?

    i.e. A description of the business need for and the content of the following (i.e. how they differ from the provided OOTB functionality):

    1. The custom Application Case Type
    2. The custom Schema
    3. The custom IEG script

    It is based on a description of this business need that we would be able to ascertain whether there are other means of achieving this (e.g. like customizing the ProcessIntakeApplication workflow instead to do something different for your custom process rather than touch this class).

    Thank you,
    Shane McFadden, Cúram SPM Product Management team

  • Guest
    Reply
    |     Jun 16, 2020

    Hello. Thank you for the feedback. I have sent the attachment to 'shane.mcfadden@ie.ibm.com' as directed. Please let me know if you don't receive it.

    Thank you,

    Maribeth Kane

  • Guest
    Reply
    |     Jun 16, 2020

    Hello. Thank you for the feedback. I have sent the attachment to 'shane.mcfadden@ie.ibm.com' as directed. Please let me know if you don't receive it.

    Thank you,

    Maribeth Kane

  • Guest
    Reply
    |     Jun 10, 2020

    Hi Maribeth,

    You can email the attachment to this address 'shane.mcfadden@ie.ibm.com' and I'll make sure we evaluate the extra information you provide.

    Thank you,
    Shane McFadden, Cúram SPM Product Management team

  • Guest
    Reply
    |     Jun 9, 2020

    Hello. I am unable to attach the files which provide additional detail per your request. Please advise how I can send these files to you for your continued investigation.

    Thank you,

    Maribeth Kane

  • Guest
    Reply
    |     Jun 9, 2020

    Hello. Attached is a zip file which provides the detail requested. Please let me know if you have any other questions.

    Regards,

    Maribeth Kane

  • Guest
    Reply
    |     Apr 23, 2020

    Hello. Thank you for your response. I am still waiting to hear from the developer regarding your query. As soon as I hear back from him, I will post his response here.

    Regards,

    Maribeth Kane

  • Guest
    Reply
    |     Mar 30, 2020

    Hi Maribeth,

    In order to evaluate your request, we require that you provide more detail so that we can fully understand your requirements.

    In particular to get more detail on why you need to invoke a brand new workflow for this process. The ProcessIntakeApplication workflow is what is called for all OOTB application submissions.

    A description of the business need for and the content of the following (i.e. how they differ from the provided OOTB functionality):

    1. The custom Application Case Type
    2. The custom Schema
    3. The custom IEG script

    There may be other means of achieving this (e.g. like customizing the ProcessIntakeApplication workflow instead to do something different for your custom process rather than touch this class).

    If we do not receive this information within 30 days, this request will be closed.

    Thank you,
    Shane McFadden, Cúram SPM Product Management team

  • Guest
    Reply
    |     Mar 13, 2020

    Hi Maribeth,

    Thank you for your enhancement request.
    We require some further analysis to determine whether or not this enhancement can be considered in a future release.
    I will provide another response when our investigation is complete.

    Thank you,
    Shane McFadden, Cúram SPM Product Management team