Ability to extend Advance Evidence Sharing work flow

Hi Santosh,

We have some further questions on this. I'm posting the questions here but I think it might be easier if we have a meeting to chat through this as a team. I will pencil in some time for next week. If that doesnt suit, let me know and I can reschedule.

Regards,

Angela

End Date on Insert

When AES inserts evidence onto the target case during the Deliver Shareset workflow activity, the customer is requesting a hook to be able to end date other evidence on the target case. Is that correct?

• How will this other evidence be a) identified and b) modified - is that all to be done via custom logic?

• Is this only during authorisation, or for evidence sharing in general?

• Is the evidence to be end dated part of the current share set or could it be outside of it?

Inserts onto Incoming

If the trigger evidence is inserted onto the incoming screen for some reason, should the hook still be called? What’s the expected behaviour in this case?

End Dating on Multiple Cases

In the address example provided, an address is end dated on the Integrated Case during sharing. What should happen if that change should be shared to other cases (e.g. Person Case)?

Since the update is made inside the sharing workflow, it won’t trigger the usual sharing logic. How should updates to other cases be handled in this situation?

Activating End Dated Evidence

For the AES push workflow, AES will attempt to auto-activate evidence in a later step. However, if the end-dated evidence isn’t part of the share set, it won’t be auto-activated. Would you expect it to be?
Or do you have something else in mind for how this should work e.g. another hook point, or something you’re expecting Cúram should handle?

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