willdwyer / bcbsmaissuestracker

Automatically exported from code.google.com/p/bcbsmaissuestracker
0 stars 1 forks source link

Benefit cost share changed to junk value #181

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Log on to PClient5 as a BCBSMA Administrator
2. Click on Manage Plan
 Enter search criteria:
 Effective Date - 2015
 Financial Arrangement - Insured
 Market Segment - Large Group 100+
 Product Type - PPO
 Plan Type - Custom
 Click - Show Me Plans"

3. Select 
3418172 Network Blue New England Options Deductible v.4 Gold Medal Bakery and 
click plan document options and 
4.Generate Final PDF with disclosures through plan options. 
5. preview page 2

Actual Result:
The Enhanced benefit tier value for other practitioner office visit is changed 
to #N/A even where no such change was made. This cost share was not even 
modified during customization and it should been the default value from 
standard base plan

Expected Result:
System should not junk benefit cost share in this manner.

Test Case #
E2E_14

Original issue reported on code.google.com by g4gaur...@gmail.com on 11 Jun 2015 at 3:01

Attachments:

GoogleCodeExporter commented 9 years ago
Issue has been shared with HighRoads team and is being reviewed.

Original comment by Tim.at.H...@gmail.com on 11 Jun 2015 at 3:15

GoogleCodeExporter commented 9 years ago
I do not see this plan design when I search in the Configurator with that 
criteria. I searched in pclient5 directly in Search for this plan design name 
and it doesn't come up.
Unfortunately I don't want to leave it at this and have another defect 
resubmitted when and if the issue is seen again, but I cannot troubleshoot if I 
cannot recreate.

Original comment by michelle...@gmail.com on 11 Jun 2015 at 5:42

GoogleCodeExporter commented 9 years ago
BCBS will look to demo this issue at today's meeting.

Original comment by Patrick.C.Commander on 11 Jun 2015 at 6:11

GoogleCodeExporter commented 9 years ago
3416171 can be used as a reference.

Original comment by Tim.at.H...@gmail.com on 11 Jun 2015 at 8:02

GoogleCodeExporter commented 9 years ago
Retested with original plan used to create 3416171, 600353, as Will is locked 
in that plan. I created a new custom plan from this one to test how the values 
were brought over (the '#N/A' is in the Other Practitioner Office Visit Lowest 
Cost Share field of 3416171). The value was brought over to the new plan, 
3421168, correctly and the SBC generated correctly. I don't know what edits 
were made to the former custom plan, as it's locked. But when a user sees a 
value like this in the plan design, they should correct it and then 
Save/Generate the SBC.

Cannot recreate issue without manually adding in #N/A and the system is working 
as expected if it finds this value as it's not a valid value. Please retest.
Thank you.

Original comment by michelle...@gmail.com on 12 Jun 2015 at 2:16

GoogleCodeExporter commented 9 years ago
HR still cannot reproduce this item.  Did not discuss in detail during 
yesterday's defect meeting due to time.  Assigning to Gaurang.  We should look 
to verify that this issue is still reproducible and then look to demo at our 3.

Original comment by Patrick.C.Commander on 12 Jun 2015 at 5:55

GoogleCodeExporter commented 9 years ago
HR to look for occurances of 'junk value' issues prior to push to prod.  see 
also:  175, 176, 181

Original comment by Patrick.C.Commander on 12 Jun 2015 at 9:34

GoogleCodeExporter commented 9 years ago
assigning to HR as part of the junk value update 

Original comment by Patrick.C.Commander on 15 Jun 2015 at 7:48

GoogleCodeExporter commented 9 years ago
Priority has been set as showstopper level 2.  This issue is part of the junk 
value workstream that HR owns.

Original comment by Patrick.C.Commander on 16 Jun 2015 at 2:12

GoogleCodeExporter commented 9 years ago
Regarding our issues with “junk values” and/or values of N/A… it appears 
to mainly caused by a workbook formula that had a misspelling within it. We are 
doing a thorough review of the workbooks to ensure there are no others.

Original comment by Tim.at.H...@gmail.com on 16 Jun 2015 at 2:19

GoogleCodeExporter commented 9 years ago
fixes to be bundled by HR.  Aim is for HR to deliver tomorrow afternoon.

Original comment by Patrick.C.Commander on 16 Jun 2015 at 7:18

GoogleCodeExporter commented 9 years ago
All workbooks have been reviewed and fixed where needed. Tested and confirmed 
no junk values appear.  Ready for retest.

Original comment by Tim.at.H...@gmail.com on 17 Jun 2015 at 3:34

GoogleCodeExporter commented 9 years ago
BCBS will retest this item.

Original comment by Patrick.C.Commander on 17 Jun 2015 at 7:38

GoogleCodeExporter commented 9 years ago
testing to continue through EOD.

Original comment by Patrick.C.Commander on 18 Jun 2015 at 6:53

GoogleCodeExporter commented 9 years ago
I have been unable to reproduce this one so far. Can be closed.

Original comment by g4gaur...@gmail.com on 19 Jun 2015 at 5:27

GoogleCodeExporter commented 9 years ago
closing per above.

Original comment by Patrick.C.Commander on 19 Jun 2015 at 5:43

g4gaurang commented 9 years ago

A BE user experienced a situation where when she entered text appending an existing L&E value/text for Imaging on the interface and save it, it turned into a junk value (#value!)

Plan design is 3459290_Stratus Technologies_Network_Blue_NE_Ded_154799BS

This may or may not be reproducible immediately when you try to replicate it on Pclient5/Prod. but we would like you to review and fix the capture file formula for invalid references and ensure this does not happen again.

image

image

image

TimHeasley commented 9 years ago

Gaurang, Can you offer more detail as to what the text was that the BE entered?
Thanks, Tim

g4gaurang commented 9 years ago

Here it is Deductible applies first; copayment applies per category of test / day; copayment limited to $375 per member per calendar year; pre-authorization required for certain services

TimHeasley commented 9 years ago

Guarang, We have tested out the values in multiple workbooks with the Limitations string you sent and we are not seeing any errors in PClient5. Please retest at your convenience. Thank you, Tim

g4gaurang commented 9 years ago

Tim, as I indicated above, you may or may not be able to reproduce the defect immediately but the fact is it has occurred on the said plan in production. The question is can you investigate and/or tweak your cell reference formula for that field appropriately so that the #value! does not show up again unexpectedly or do you do nothing and just wait for another recurrence of a similar issue in the future ?

sayotte7701 commented 9 years ago

Hi Guarang. I don't think our intention is to do nothing on this. What would really help us is to have the text string which caused the issue. Having that data would allow us to reproduce the issue and then take decisive action on tweaking the formula. What I'll do is carve out some time tomorrow to see if I can reproduce the issue. If I cannot, we can close this issue for now as not reproducible. If it does happen again, lets try and get the exact text string.

g4gaurang commented 9 years ago

Here it is Deductible applies first; copayment applies per category of test / day; copayment limited to $375 per member per calendar year; pre-authorization required for certain services

This is the exact string that the BE provided.

g4gaurang commented 9 years ago

Can you put in a IFERROR(value, value_if_error) error handling mechanism for this service to ensure such error messages do not leak out to the UI/document ?

g4gaurang commented 9 years ago

The BE users are running into this same issue on the same plan again as they finalize the plan to send to the account. I am attaching the draft SBC here. copy the Imaging L&E from the SBC document as is and paste it in the Imaging L&E field on the UI and click save. Notice the #value! tag re-appear.

Plan design is 3459290_Stratus Technologies_Network_Blue_NE_Ded_154799BS

the BE user recreated this issue a few times.

image

image

154799BS_Stratus Technologies_NBNE_CLIENT_10-29-15.pdf

michparrish commented 9 years ago

Thanks, Gaurang - this seems to happen after 2 or more saves, but not one. We're investigating the issue.

TimHeasley commented 9 years ago

Guarang, We have updated the logic if an error (junk value) is encountered, the original text in the field will remain. It has been tested in PClient5 and confirmed working. Please retest at your convenience. Thank you, Tim

g4gaurang commented 9 years ago

Tim, can you tell us what you changed in the logic ?

TimHeasley commented 9 years ago

Guarang, The original Imaging Limitations logic is still in place and will work as intended. If, for some reason, it errors out on the back end, whatever the user has entered will be kept and will appear correctly. Same thing if the user selects “No cascade” for Imaging Cascade. It allows the user to enter whatever string into limitations they want without the preset logic interfering, as was the intention with it.

Essentially, in addition to fixing what was causing the error in the first place, there’s an overarching IFERROR() around it that will keep whatever the user entered if the Imaging formula errors out. Thanks, Tim

g4gaurang commented 9 years ago

Changes look good on Pclient5. Please move to production.

TimHeasley commented 9 years ago

Guarang, Thank you for testing. We will move to Production and let you know when it is ready for retest. Tim

TimHeasley commented 9 years ago

Guarang, The changes have been moved to Production and are ready for retest. After approval/confirmation please close the issue. Thanks, Tim

g4gaurang commented 9 years ago

Looks good in production.