Ability to extend Advance Evidence Sharing work flow

Hi Santosh,

Thanks for getting back to us on this but it is still a little unclear what the customers is trying to acheive from a requirement perspective esp with the new information on end-dating existing on insert. Could you provide us with with an understanding of the business case, including a few example scenarios including evidence types as well as the logic behind the system’s behaviour during sharing, and how it determines whether to insert or end-date evidence (or not end-date evidence). This would help us determine how best to support the intended functionality.


Regards,

Angela

We recently found out that - for evidence types with Maintenance pattern of "Multiple". Business expects that we end date the existing evidence and then create a new one (Insert).

OOTB for identical evidence there is no option to end date the existing evidence and create a new one from the source case.

Hi Santosh ,

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:

•          Ability to compliantly customise the evidence sharing workflow to meet specific requirements from Minnesota

We understand there are two separate requests included;

1. Prevent Auto-Activation of Evidence During AES Push

When an Application Case is authorized to an existing Integrated Case (IC), evidence shared during this process is auto-activated—even if some of it is in the incoming queue. This can lead to premature downstream processing (e.g., incorrect product delivery creation). Minnesota want a hook point to enable them to prevent this auto-activation.


This request is clear, no further questions on this one.

2. Auto End-Dating of Evidence Not Present in Application Case 
When data is received from the Get Insured (GI) system, it creates an Application Case in Curam. Upon authorization to an existing IC, Minnesota wants to automatically end-date:

* Applicant Details evidence for members present in the IC but not in the Application Case.

* Other evidence types that are present in the IC but not in the Application Case.

This request appears to go beyond evidence sharing. It involves identifying and end-dating evidence (and/or members) on the IC that are not present in the Application Case. At first glance, this seems more aligned with post-authorization processing rather than evidence sharing itself. We would like to understand the following to see if that provides more context to this request:

* At what stage in the workflow are Minnesota currently applying these end dates?

* Is there a reason this logic must be embedded in the AES workflow?

* Could this be handled as a post-authorization step outside of AES?

Thank you,

Angela Brady, Cúram Product Management Team

MN is looking for some compliant hook points to achieve these requirements. MN currently has extended the AES push work flow ( this is an internal workflow used by the AES component and it is non-compliant) to achieve this functionality. Any non-compliant customisation causes issues with future upgrade and hence requesting hook points from the product to implement these requirements.

One more scenario that I forgot to add - Business also does not want to acitvate evidence when an application is authorized to an existing case and if any of the evidence is in the incoming queue. For this requirement , MN had to non-compliantly customize the AES workflow to achieve this.

Hi Santosh ,

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