wk3 aug_epic: SimUI Bug URGENT - Hrs Available Total Exceeds Capacity - mismatch w Team Data Table

[branscombj]

In the Experiments Section/Supply/Appointment Supply, the Total hours available should include the hours in the base case for services that you do NOT alter for an experiment as well as those you changed. Ideally, therefore, Total would always populate and in the bc it would show the same number as that in the Team Data Table. Currently, it only shows the total for services you moved off of bc.

[lijenn]

Discussed 8/17 Facilitate WG:

Zimmerman, Lindsey E. 9:16 AM "! You have exceeded supply" warning message Experiment Slider Total = 27 exceeds Team Data Total = 26

We want to only grow your "Appointment Supply" pie intentionally.

BUG: Right now "Total" in the experiment slider is not adding the BC values, only the adjustments made (i.e., the number).

• Intermediary solution: You can add the basecase values from the team data table to the sliders in the Appointment Supply section. Then, when you adjust the sliders, the total will accurately calculate if you're exceeding your "pie"

[jamesmrollins]

Hi @hirenp-waferwire . Please implement the following adjustment to Agg model Appointment Supply. Please route and hold in BreakFix until you receive notice to move to PROD.

[jamesmrollins]

Hi @lzim @staceypark @lijenn @branscombj this is now available on BreakFix for evaluation.

The base case total from team data is now showing as the total in the Appointment Supply. When you manipulate the slider, it will add that to the base case total and likely set off the "You are exceeding supply" alarm.

Base Case Total Appointment Supply Now the Total.

WIth appointments added to BC

If all agree with the fix, I can promote tonight to PROD.

[branscombj]

@jamesmrollins Not sure the above is working correctly. In the example shown, the bc for Psy is 9. The slider set at 3 should yield a lower total. Need to replace the bc value with the slider value, whatever the slider value is set to if other than bc.

[jamesmrollins]

Hi @branscombj

Yes, I see the problem. I am having a hard time figuring out how to do this. BC means the variable connected to the slider is set to -1. That trigger returns the BC value, in Psy for example, of 9. The slider has a direct relationship with the value reflected in the box. I am not sure I can reflect the base case values with the sliders in the actual position upon boot-up of the simulation.

What I may be able to do, is provide a button that runs a browser level routine that reads the base case values from the data variables in the team data table and sets the sliders to those values. Then leave the "You have exceeded supply" logic the same (because it always fired off when you exceeded total supply).

[branscombj]

@jamesmrollins I know that when you first created this, using -1=bc was the best workaround. Plus we liked having 2 visual cues that a slider was set to bc: the "bc" in the label box and the slider at far left. However, I wonder if there've been any developments in things since then that would allow you to have sliders default to sitting at the bc levels from the Team Data Table, and have the label box read "bc" when the slider is set to that Team Data Table value. I.e., if I'm advancing the Psy slider to the right, the box would say "7", "8", "bc", "10". And have total at the bottom add the true value of the slider setting, whether bc or other.

Hope this makes sense. I don't need an explanation if you can't, feel free to Just Say No - still not doable. I just thought I'd ask, since this is what would be the cat's pajamas!

[jamesmrollins]

Hi @branscombj . Yes, what you are saying makes sense, but I don't have the capability. The "BC" is linked to the -1 value. What I thought might get close is to provide a button you could click that would advance the sliders all to the BC actual value. Then you would reflect the appropriate total and have the proper activation of the warning.

[branscombj]

Hi @branscombj . Yes, what you are saying makes sense, but I don't have the capability. The "BC" is linked to the -1 value. What I thought might get close is to provide a button you could click that would advance the sliders all to the BC actual value. Then you would reflect the appropriate total and have the proper activation of the warning.

Got it. I can see some awkwardness to that, but it might be best. Would like to request additional input @lijenn @staceypark @lzim

[lijenn]

@branscombj @jamesmrollins Yes, the button might be a little awkward. If that is the only solution, I think we'd also need the Appointment Values to be blank on default instead of how it is right now which just says BC?

James, would the BC values that the button would pull show the BC value as "BC" as Jane described ("7", "8", "BC", "10") or the actual value/number?

When considering the guide and .gif changes, I'd vote for it show as BC since that's how it's shown in our documentation and still keeps the BC language in the SIM for the Facilitators and Learners.

[lzim]

@branscombj @jamesmrollins @lijenn @staceypark

I'm not sure I'm tracking all the ideas going on here, what do folks mean by "awkward?" I'm struggling to track how the Appointment Supply feedback is working for the user (Learner & Facilitator) in TEST now.

Here's what makes sense to me given the "i" information for the Slider:

The Total Appointment Supply in the Team Data Table and the Appointment Supply slider both = 43 appointments.

Here's what doesn't make sense to me given the "i" information for the Slider:

I adjust PSY to 1 and = 44 and alerts me about exceeding supply, when the Team Data Table value for PSY is 9 hrs/wk. So, when I adjust PSY to 1, I should be seeing the total = 35 (43 Total Appointments - 8 PSY Appointments = 35 Total hrs/wk; adjusted down from PSC BC of 8 hrs/wk)

My conclusion: The slider is tracking the values in the slider as additions only (??) and not quantifying the discrepancey from the "BC" value in the Team Data Table.

@jamesmrollins Is that intentional? The way it needs to work?

• If no, please advise.

• If yes, I would suggest we'd need to edit the appointment supply slider "i" information below to reflect what it is actually doing:

Appointment Supply The number of official appointments offered each week. This value replaces the default value estimated from the team's data, with the assumption that any increase in supply comes from reducing appointments offered in other services. (appt/wk)

[jamesmrollins]

Hi @branscombj! I think we have a solution.

Need to adjust the calculation for the total field only for each service:

User Psy Appointment Supply - Data Psy Appointment Supply + Total = Total adj.

Example:

Data Psy Appointment Supply = 9 User Psy Appointment Supply = 1 Appointment Supply Total = 43

1 - 9 + 43 = 35

[jamesmrollins]

@hirenp-waferwire please see discussion above for adjustment of "Total" field calculation.

[jamesmrollins]

Hi @branscombj @lijenn @lzim @staceypark I believe it is working as you want. See examples below. If everyone is good, this will be available in PROD tomorrow morning.

User Psy Appt Supply (4) - Data Psy Appt Supply (9) + Appt Supply Total (43) = Adj Total (38)

[User Psy Appt Supply (4) - Data Psy Appt Supply (9)] + [User Adj Appt Supply (23) - Data Adj Appt Supply (17)] + Appt Supply Total (43) = Adj Total (44) ! You have exceeded supply

[lijenn]

Thanks @jamesmrollins! I tested this in https://mtl.how/test and it looks great (tested multiple services in supply and decimal values as well).

If anyone else does not see any issues, I think we can promote to prod. fyi @branscombj @lzim @staceypark

[lzim]

Discussed at hq_workgroup @staceypark will test this afternoon and then we'll plan to promote to PROD tonight.

[staceypark]

@jamesmrollins I used my break-fix test world (only have one). The calculator works fine for non-zero numbers, but it's treating basecase and zero as the same. Meaning, when I use "zero", it actually uses the BC numbers.

See screenshots below:

[lijenn]

Nice catch Stacey!!!

[branscombj]

Wow that IS a good catch

[jamesmrollins]

Hi @branscomj @staceypark @lijenn I didn't see this until this morning. This is now is PROD. And I am having trouble understanding the issue without the values from the Team Data table. Can you provide a screen shot of these please?

The behavior should be: User Adjunctive Appt. Supply (0) - Data Adjunctive Appt. Supply (x) + Appt. Supply Total = Adjusted Appt. Supply Total.

So the zero condition would mean the Team Data supplied Adjunctive Appt. Supply would be subtracted from the Appt. Supply Total. Are you saying the BC value is not being subtracted from the total in the zero condition?

Please confirm - this is an easy fix and can be accomplished before Monday.

[lijenn]

Discussed 8AM Workgroup Leads:

Thanks @jamesmrollins for fixing the issue with the 0s! @staceypark & @lijenn will do a final test, but this is rolled out in Prod already.