Hi Jennifer,

As per the current implementation of the system the plan termination rule set on the company level will be applicable to plans for which there is no rule set for plan termination. But here for FSA plan the termination policy is set as Date of Plan Termination, so as per current implementation system should apply this rule set on the plan for termination date. Further we tried to check why this date is being set for FSA enrollment termination. We will investigate more on this and get back to you as soon as possible.

Thanks,
Venkatesh

Swapnil PandharePlease check this.

Concern:

Enrolled in FSA 11/01, then waived. The term is showing 9/30 instead of 10/31 (the day prior to the actual
enrolment effective date). Is this how we should expect it to work?

Cause:

This is as per system implementation.

Employee must have waived this election with New Hire Mode which is effective with 10/1.
Hence, system have termed the election with date 9/30.
System considers the mode effective date and not plan effective date while terming the elections as never effective.

Please let us know if more details required.

Jennifer LeugersPlease check and confirm.

Hi all - not sure why this is marked as resolved. Please see below from UHC.

Hi all - not sure why this is marked as resolved. Please see below from UHC.

This is definitely an issue that development will need to resolve. Luckily our BP is to build the smallest waiting period at company level. If the greater NH waiting period is built at the Company level – the system is giving the employee a month of coverage they aren’t eligible for when termed as never effective. The system needs to look at the company and plan level rules to ensure the term as never effective logic applies correctly on a NH/RH. See the below test completed to validate.

I tested this in Almac in Stage. I left the company level NH/RH rule as FOM following or coincident with Date of Hire. I then set the medical NH eff date Rule to DOH.

I hired an employee effective 02/02/16 – I enrolled in Choice HSA and then waived coverage. The system is giving a month of coverage on a term as never effective. See the below screen shots.

Hi Jennifer,

In mentioned customization greater NH waiting period is set at Company level than at plan level.
In this customization, plan's effective date is less than New Hire Effective Date.
Is this a valid customization and will it be in use?

If yes, then we need analyse the code changes for the same, as existing Enroll Now routines should not be affected.

Please verify the same and let us know.

Please see comments below

Our current best practice is to put the lowest waiting period at the company level based upon issues pertaining to enrollment tunnel experienced in past (e.g. since enrollment mode eff date was based on company level rule (future date) when deps were needed to be added for any plans where plan eff date was earlier the system would prevent as dep was also added to system with a future eff date (equal to company level rule) and plans with earlier plan level eff dates not showing for NHs).

It was advised that the system was being enhanced to be able to handle the smaller/larger rule at either plan/company level. It was also described (on many occasions) that the bulk of EBS Clients were set up to have the greater rule at the company level and the smaller if variance at plan level. We would have no way to validate this statement but you may want to run a scan as this term as never effective logic is definitely an issue in a scenario where the rules are inversed.

If yes, then we need analyze the code changes for the same, as existing Enroll Now routines should not be affected. Please let us know what direction is taken on this.

Swaraj PatilAssigning to you. Please check and update.

Hi Jennifer,

We have started analysis of this implementation at our end. We will share analysis and ETA for this by 03/01/2016.

Hi all - my UHC call is at 10 AM PST today. Any updates on this?

Hi all - really need an update please.

There are two parts in this.
1. Terminate as never effective should be set to Effective date -1 Amnesh Goel
2. If additional field value has been changed then plan should not be allocated for 1 month (in this case plan should be terminated as never effective as -1 days) Swapnil Pandhare

Swapnil & Amensh - please share analysis details for this.

Hi Jennifer Leugers,

We are working on it and we will keep you informed on this.

Thanks,
Amnesh Goel

Hi Jennifer Leugers,

As per current system implementation, during waive, system terms plan by mode effective date -1. We need your help to understand this. In this ticket we are discussing following two use cases.

1. Smaller rule at company level than plan level: In this case, enrollment is getting terminated with past date and enrollment is getting dead. However system is taking term date as one day prior to mode effective date and expected is one day prior to benefit effective. But please advise if this really making any difference because employee benefit is terminated with a past date and he never gets that benefit. Other modules are also treating that employee benefit as dead one.
2. Smaller rule at plan level than company level: As per current implementation if this setting comes into play then employee will get plan for some duration even if he elects and waive on the same day. We need your help to understand that is such setting really comes into picture and do we need to handle this.

Please advise.

Thanks,
Amnesh Goel

Jennifer LeugersPlease check and update.

Smaller rule at company level than plan level: In this case, enrollment is getting terminated with past date and enrollment is getting dead. However system is taking term date as one day prior to mode effective date and expected is one day prior to benefit effective. But please advise if this really making any difference because employee benefit is terminated with a past date and he never gets that benefit. Other modules are also treating that employee benefit as dead one. Agreed it is being treated as a dead record but it causes un-necessary questions to be raised by the Client as the end date is much earlier than the start date identified.

Smaller rule at plan level than company level: As per current implementation if this setting comes into play then employee will get plan for some duration even if he elects and waive on the same day. We need your help to understand that is such setting really comes into picture and do we need to handle this. Our opinion is yes – we were advised the logic/functionality would be fixed to allow us to identify whichever rule is more common regardless of smaller/greater at the company level. It would cut down on build as less settings would need to be set at plan level if the most common rule could be set at company level. Our original BP identified was the result of all of the issues we initially identified when we built the more common rule for FDU (which happened to be the greater) at the company level. Thankfully, we don’t have any of our Clients currently built this way – however, the system should be able to accommodate this logic.

Amnesh GoelPlease update.

This task is schedule to be part of Sprint 1 which will start from 4/1/2016.

Hi Amnesh,

I have updated Item state - to Development Backlog for this.

As discussed, can you please share ROM estimates for this, so we can schedule it accordingly.

Thanks & Regards,
Satya Prakash

Hi all - could we get estimates on testing, deployment, etc. for this? Thanks!

Hi Jennifer Leugers,

This task is not yet scheduled for development due to unavailability of bandwidth. We will check for estimates and will update the ticket.

Jyoti Mayne and Amruta Lohiya - Please help in getting the ROM estimates for it.

Thanks,
Amnesh Goel

Any updates on this?

Please confirm tentative date for completion is 5/19/16.

Hi all - need a response please.

HI Jennifer Leugers,

We working on this item last week to understand the changes that will required in system. We also had design team meeting to discuss this change and its impact and we also had discussion with Amit on this.

I feel Jyoti Mayne would be having some strategy on place by now.

Jyoti @ Please update this ticket with ETAs. We will schedule this item soon for development then.

Thanks,
Amnesh Goel

May 19:- We have discussed with team and decided to take this task on priority and will deploy on May 26 on our local harbinger environment. We will deploy this on stage on May 31 , if everything goes fine on our local environment.

Jyoti MayneAmnesh Goel Kindly update with Analysis document so that we can start with test case writing

This task is carry over to Sprint -4
Dev Estimation for Sprint 4 is : 24

8 Hours work done in sprint -3
24 hours work will be done in Sprint-4

[~meghana.kulkarni] Kindly start with test case writing for this enhancement.

Jyoti MayneAmnesh Goel Kindly update with Analysis document so that we can start with test case writing

Hi Deepali Tidke,

Below are the implementation details:

If both Company level and Plan level effective date rule are specified and different
In this case we will check if election effective date is matching with plan level effective date rule then we will term election with election effective date-1 while waving a plan from enroll now screen.

We will be doing this for Open enrollment, New Hire and Rehire modes.

Please find below example of new hire:
Customization:
1. Plan Level Effective Date Rule = First of month following 30 days of Date of Hire
2. Company Level New Hire Effective date Rule = Date of hire
3. Employee Date of Hire = 10/1/2016
If employee is having enrollment from 11/1/2016 to NULL. When employees goes to enroll now screen he will get
Mode Effective Date as = 10/1/2016
Plan Effective Date as = 11/1/2016

When employee waives plan then system will do following:
Effective Date Termiantion Date
1. 11/1/2016 10/31/2016 – employees 11/1/2016 election got terminated with 10/31/2016 date [Earlier system was terming election with 9/30/2016 as per ModeEffectiveDate-1 ]
2. 10/1/2016 NULL – waived details

Hi Deepali Tidke,Rakesh Roy,

Today while doing code review, new scenario was came up and I was working on priority LHP correction.
So I didn't get chance to look for the new scenario today. I will check it tomorrow and convey Dev due date by 5/27.

Hi Deepali Tidke,[~meghana.kulkarni],

Please consider below scenarios for impact testing:
1. Both OE and NH modes are on
2. Only NH or OE or RH mode on
3. Individual Plan level waive setting
4. Benefit level waive setting
5. For Contingent plan

Hi Deepali Tidke,

Started test cases writing of Enhancement.

Test cases writing completed for individual New Hire/ Rehire / Open Enrollment / Class wise OE modes for Benefit level Waive Setting.

Test Cases writing is in progress for below points :
Both Modes ( New Hire and OE )
Contingent Plan
Individual Plan level waive setting

PFA

Thanks & Regards,
Meghana Kulkarni

Hi Deepali Tidke,

Completed test cases writing for below points :

Contingent Plan
Individual Plan level waive setting

Test cases writing is in progress for below Point

Both Modes ( New Hire and OE )

PFA updated test cases sheet.

Thanks & Regards,
Meghana Kulkarni

Updated test cases for Both Modes ( New Hire and OE )

PFA

Hi Deepali Tidke,

I have started testing of enhancement on LB , for verifying the enhancement Jyoti Mayne has given script for testing.

Simultaneously , updating test result in test case document.

Thanks & Regards,
Meghana Kulkarni

Testing is in progress on LB and found issue in Contingency [ Created Jira - WT 2825 ].

Testing is completed for below points :

Only NH or OE or RH mode on
Individual Plan level waive setting
Benefit level waive setting
For Contingent plan

Testing is in progress for : Both OE and NH modes are on

Testing is completed on LB.

Jira status [ Item Status - Ready For Stage ] will be update ones the reported issue [WT 2853] is solved and verified on LB.

Hi All,

Recently during QA of this development, QA identified an issue.

We are working on it and finalizing the approach to fix this issue and this is why this ticket is experiencing a delay.

I have done the analysis and it needs proper review by Amruta Lohiya before we start fixing it. Since this bug is in core component of contingency and impact is severe, it needs proper attention before it moves out to Stage and Production.

So I'm waiting for Amruta's time on this and I'm expecting that I'll get her time on Monday 6/13 and accordingly I'll be in position to share more updates on it.

Thanks,
Jyoti M

Satya Jyoti Mayne :I do not see any movement from last 3 days. Can you please look in to this?

Hi shyam sharma,

Today, I got helped from Amruta regarding this task. I will complete it by tomorrow first half. It will get deploy on LB by 6/15 3.30 p.m patch.

Jyoti Mayne : could you please update current Progress for this task ? This task is from sprint 4 and by this time it should be on production or completed
Satya

Hi shyam sharma,

This enhancement had one bug reported by QA WT-2825 and fix for same was deployed LB on 6/15 IST.
Currently this task is in QA testing. As per QA estimation, it will be deployed on Stage by 6/22 IST. Status is updated in Jira.

Once WT-2825 gets completed on stage, will give production date.

Verified all mentioned test cases on LB.

Working Fine

Testing is in progress on Stage

Verified all mentioned test cases on Stage.

Working Fine

Verified all test cases on Production.

Working Fine